Struktura bazy
Andrzej
Mam nastepujacy dylemat przy tworzeniu struktury bazy
Jest baza danych "n" produktow. Cena kazdego produktu jest
wyliczana za kazdym razem dynamicznie na podstawie
ok. 20 do 40 parametrow konfiguracyjnych, ktore moga
ulec zmianie w kazdej chwili. Parametry moga zostac ulozone
w ok. 3 do 8 tabel, ktore beda powiazane ze soba relacjami.
Nie ma klucza, za pomoca ktorego mozna by wyroznic
jakis powtarzalny schemat i zrobic jedna strukture konfiguracyjna
dla wszystkich produktow.
Wszystko przy zalozeniu, ze liczba produktow "n" zwieksza
sie w miare czasu 2 do 50 (i byc moze wiecej).
Moj dylemat to:
1) Czy rozwiazac wszystko za pomoca tabel, co przy
np. 50 produktach x 5 tabel (srednio) da nam 250 tabel
w kazdej tabeli maksymalnie po kilka rekordow.
Przy wyliczeniu ceny musze otworzyc te 5 tabel, dokonac
obliczen i wyrzucic gotowa cene. Jesli ktos w koszyku ma
"k" produktow, to musze za kazdym razem otwierac srednio
k*5 tabel.
2) Czy rozwiazac to za pomoca plikow konfiguracyjnych
np. cos a'la pliki INI, w ktorym beda zawarte wszystkie parametry
(Jeden plik - wszystkie parametry). Przy 50 produktach da nam to 50 plikow.
Jesli ktos w koszyku ma "j" produktow, to za kazdym razem otwieram
tylko jeden plik konfiguracyjny - co daje nam j otwieranych plikow.
PHP, MySql
Jakbyscie Wy rozwiazali podobny problem?
--
Pozdrawiam
Andrzej
pawel
ale z praktyki baz danych narzuca się rozwiązanie że zamiast tworzyć 50
tabel lub 50 plików
utworzyć jedna tabelę z 50 typami rekordów (...)
Paweł
Andrzej
> Jest baza danych "n" produktow. Cena kazdego produktu jest
> wyliczana za kazdym razem dynamicznie na podstawie
> ok. 20 do 40 parametrow konfiguracyjnych, ktore moga
> ulec zmianie w kazdej chwili. Parametry moga zostac ulozone
> w ok. 3 do 8 tabel, ktore beda powiazane ze soba relacjami.
Zapomnialem dodac, ze liczba parametrow konfiguracyjnych moze
ulec zmianie np.:
produkt K jest okreslany za pomoca nastepujacych parametrow:
- tabela: a(kolor, faktura_powierzchni) - 3 rekordy
(czerwony, porowaty) (zielony, gladki) (niebieski, szorstki)
- tabela: b(szerokosc, wysokosc, dlugosc) - 5 rekordow
(10,10,10) (20,15,5) ...itd.
I teraz a*b daje nam 15 mozliwosci po 5 parametrow w kazdym
(czerwony, porowaty, 10, 10, 10)
(czerwony, porowaty 20, 15, 5)
itd.
Liczba tabel srednio 3 do 8.
Liczba rekordow w kazdej z tabel 1 do 10.
Liczba rekordow w kazdej z tabel jest zmienna. Operator musi miec
mozliwosc dodawania i usuwania rekordow.
To wszystko jeszcze nalezy przemnozyc przez N produktow
(2 do 50 lub wiecej). I kazdy produkt ma inne tabele, inaczej
wyliczana cene.
Przyklad jest teoretyczny.
--
Pozdrawiam
Andrzej
pedroz
[...]
> Moj dylemat to:
> 1) Czy rozwiazac wszystko za pomoca tabel, co przy
> np. 50 produktach x 5 tabel (srednio) da nam 250 tabel
> w kazdej tabeli maksymalnie po kilka rekordow.
???? Cos mi tu pachnie bezsensownym projektem bazy. Chcesz dla kazdego
produktu tworzyc osobne tabele? Przeciez to sie kupy nie trzyma. A dlczego
nie mozesz (jak juz napisal pawel) stworzyc slownika typow i wszystko zamknac
w tych kilku tabelach? Rozwiazanie 10000x bardziej elastyczne.
> Przy wyliczeniu ceny musze otworzyc te 5 tabel, dokonac
> obliczen i wyrzucic gotowa cene. Jesli ktos w koszyku ma
> "k" produktow, to musze za kazdym razem otwierac srednio
> k*5 tabel.
J.w.
> 2) Czy rozwiazac to za pomoca plikow konfiguracyjnych
> np. cos a'la pliki INI, w ktorym beda zawarte wszystkie parametry
> (Jeden plik - wszystkie parametry). Przy 50 produktach da nam to 50 plikow.
> Jesli ktos w koszyku ma "j" produktow, to za kazdym razem otwieram
> tylko jeden plik konfiguracyjny - co daje nam j otwieranych plikow.
Bron Boze. O tym nawet nie mysl. To nie ma najmniejszego sensu.
> PHP, MySql
>
> Jakbyscie Wy rozwiazali podobny problem?
Przemysl jeszcze raz, albo najlepiej kilkanascie razy projekt bazy, bo jak na
razie z Twoich opisow wynika, ze jest bardzo, ale to bardzo nieprzemyslany.
--
pzdr
pedroz
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
pedroz
> ulec zmianie np.:
> produkt K jest okreslany za pomoca nastepujacych parametrow:
> - tabela: a(kolor, faktura_powierzchni) - 3 rekordy
> (czerwony, porowaty) (zielony, gladki) (niebieski, szorstki)
> - tabela: b(szerokosc, wysokosc, dlugosc) - 5 rekordow
> (10,10,10) (20,15,5) ...itd.
> I teraz a*b daje nam 15 mozliwosci po 5 parametrow w kazdym
> (czerwony, porowaty, 10, 10, 10)
> (czerwony, porowaty 20, 15, 5)
> itd.
A dlaczego nie zrobisz tak:
- tabela: slownik_parametrow( parametr_id, paremetr_opis )
- tabela: parametry_produktu( produkt_id, parametr_id, parametr_wartosc)
Wszystko bedzie mozna zamknac w tych dwoch tabelach.
> To wszystko jeszcze nalezy przemnozyc przez N produktow
> (2 do 50 lub wiecej). I kazdy produkt ma inne tabele,
Nt. tego pomyslu uz sie wypowiadalem.
> inaczej
> wyliczana cene.
To chyba nie problem.
Andrzej
> Andrzej <nom...@nomail.com> napisał(a):
>
> [...]
>> Moj dylemat to:
>> 1) Czy rozwiazac wszystko za pomoca tabel, co przy
>> np. 50 produktach x 5 tabel (srednio) da nam 250 tabel
>> w kazdej tabeli maksymalnie po kilka rekordow.
>
> ???? Cos mi tu pachnie bezsensownym projektem bazy. Chcesz dla kazdego
> produktu tworzyc osobne tabele? Przeciez to sie kupy nie trzyma. A
> dlczego nie mozesz (jak juz napisal pawel) stworzyc slownika typow i
> wszystko zamknac w tych kilku tabelach? Rozwiazanie 10000x bardziej
> elastyczne.
Ten pomysl jest chybiony i wlasnie chcialem go uniknac,
gdyz nie podobalo mi sie to rozwiazanie.
Na razie mysle o rozwiazaniu tego w nastepujacy sposob:
tabela: (id_produktu, dane_konfiguracyjne)
do bazy zapisuje:
dane_konfiguracyjne - to wielowymiarowa tablica
(id_produktu, serialize(dane_konfiguracyjne))
Jednym selectem wyciagne z bazy dane_konfiguracyjne, potem unserialize(),
i gotowe.
Dlatego taka koncepcja, gdyz odczyt z bazy bedzie wielokrotnie czestszy niz
zapis. Zapis przez operatora od kilku razy dziennie do kilkunastu razy
tygodniowo. A odczytywac i tak musze wszystkie parametry dla danego
produktu przy generowaniu ceny. Dlatego wydaje mi sie, ze lepiej chyba
wyciagnac jeden rekord z bazy i raz zrobic unserialize(dane_konfiguracyjne)
niz
wyciagac wiele rekordow (30-50). Zwlaszcza, ze dane sa "wielowymiarowe"
i powiazane w rozny sposob ze soba. W przypadku wielu rekordow dostalbym
je wlasnie "liniowo".
--
Pozdrawiam
Andrzej