Witam,

Właściwie problem jest bardziej ogólny i temat powinien się nazywać: "Problem dziedziczenia w bazach danych" czy coś tym stylu, ale że potrzebuję tylko produkty sklepowe, to tak to zatytułowałem.

Chodzi o to, że w bazie przechowujemy produkty różnych kategorii, niech będą to np. okna i komputery. Dla okna przechowujemy cechy takie jak powierzchnia, kolor czy układ szyb a dla komputerów - wiadomo - procesor, ram, etc. Pomimo tych różnic są też cechy wspólne obydwu tych produktów - takie jak cena, stawka vat, obniżka ceny w %, itp. Żeby sprawę jeszcze bardziej pokomplikować zakładamy, że użytkownik może sobie np. wybrać kolor dla okna i procesor dla komputera.

Najprostsze rozwiązanie takiej relacji wygląda tak, że szykujemy 2 tabele zawierające cechy, które przechowują odpowiednio dane charakterystyczne wyłącznie dla każdej z 2 kategorii i trzecią, gdzie zapisany jest unikatowy ID produktu, cena i reszta cech dublujących się. Tyle, że potem w kodzie wszędzie straszy ciąg [php:1:a6f570f18d]<?php
...
case komputer:
...
case okno:
...
?>[/php:1:a6f570f18d] a co jeśli kategorii jest nie 2, ale 20?

W tym sensie wydaje mi się rozsądnym jedna tabela, której polem jest XML, w którym przechowywane sa cechy indywidualne produktu + rozrzucone gdzieś w katalogach aplikacji pliki konfiguracyjne, zawierające opis jak parsować poszególny typ czy jaka jest lista kolorów dla okna - taki engine byłby na pewno skalowalny, ale po 1. - trudno go napisać, po 2. ma on znaczący narzut, nawet jeśli założymy powiedzmy wykorzystanie natwynych elementów parsowania XML w PostgreSQL.

Chcciałbym w tym miejscu zapytać się Szanownych Forumowiczów, co sądzą o tym problemie i - ewentualnie - jak go rozwiązywali w swoich aplikacjach, jeśli już wcześniej się z nim zetknęli. Być może istnieją jakieś gotowe API w php lub po prostu prostsze metody rozwiązywania tego problemu.

Mógłbym zadać pytanie Panu moderatorowi, który pozostał anonimem a przeniósł mojego posta z php Pro na php? Którego z założeń: "strategia pisania aplikacji, metoda rozwoju i podnoszenia elastyczności" nie spełnia mój post? Bynajmniej nie czuję się urażony, tylko szczerze pytam na przyszłość, bo widywałem na Pro posty tego pokroju i dlatego tam to wrzuciłem, a Pan moderator się niestety nie podpisał pod swoim dziełem.

Chcialbym powrocic do tego problemu, gdyz niedlugo przed nim stane

Sam rowniez mam pewna koncepcje, ale nie wiem jak bedzie w wydajnoscia takiego rozwiazania.. W skrocie mowiac, wygladalo by to nastepujaco.

Dodatkowa tabela, w ktorej przechowujemy nazwy cech (tylko [id | nazwa]).
Nastepnie tabela lącząca (miedzy pierwsza a trzecia zachodzi relacja wiele-do-wiele) kilka cech w grupe ([id | id_kategorii | id_cechy]), ktora z kolei jest przypisana kategorii (przy zalozeniu, ze produkty z tej samej kategorii maja te same cechy, no ale raczej tak wlasnie sie kategorie dobiera..).
No i trzecia dodatkowa tabela przechowujaca same dane [id | id_produktu | id_cechy | tresc]

To tak wymyslone na szybko, wiec moglem cos przeoczyc lub o czyms zapomniec. W kazdym razie zachecam do podywagowania na ten temat, bo jest on ciekawy i nie wiem czemu pol roku temu przeszedl bez echa

PS. Przenosze na Bazy danych, tam bedzie bardziej pasowal.

a ja sobie wymyśliłęm coś takiego: ! table

id_produktu | Wartosc


w polu id id produktu w polu warotosci cech w takiej postaci

(kolor:czarny,niebieski,zielony);(rozmiar:S,M,L) idt .... Co Wy na to ?

Wiele zależy od systemu bazodanowego. MySQL jest mocno upośledzony jeśli chodzi o możliwości realizacji dziedziczenia. W PostgreSQL istnieją co najmniej dwa rozwiązania tego problemu: zastosowania tablicowego typu danych do przechowywania specyficznych cech produktów lub wykorzystanie mechanizmu dziedziczenia (http://www.postgresql.org/docs/8.1/interac...dl-inherit.html).
Obydwa pozwalają na wygodne operowanie na produktach, przy czym ze względu na elegancję rozwiązania ja skłaniam się ku wykorzystaniu dziedziczenia. Pozostaje wtedy kwestia budowy aplikacji, która pozwala zarządzać (definiować) nowe typy produktów, ale to jest kwestia wtórna wobec modelu danych.