+- Forum Webmastera, HTML, CSS, PHP, MySQL, Hosting, Domeny - Forum dla Webmasterów (https://www.webmastertalk.pl)
+-- Dział: Technologie internetowe - tworzenie stron WWW (https://www.webmastertalk.pl/forum-technologie-internetowe-tworzenie-stron-www)
+--- Dział: Programowanie, Bazy danych (https://www.webmastertalk.pl/forum-programowanie-bazy-danych)
+--- Wątek: Jaka tabelka do przechowywania cen wszystkich kombinacji cech produktów? (/thread-jaka-tabelka-do-przechowywania-cen-wszystkich-kombinacji-cech-produktow)
Jaka tabelka do przechowywania cen wszystkich kombinacji cech produktów? - tytanick - 25-08-2012
Witam
Chciałbym poznać waszą opinię na temat rozwiązania logistycznego problemu z bazą danych jakim jest trzymanie cen dla kombinacji cech produktów.
Otóż sprawa wygląda tak:
Tabela GRUP cech o nazwie "attributeGroup" (może być nieskończoność grup, generlanie z 10)
id, name
1, Kolor
2, Wielkość
3, Materiał
Tabela WARTOŚCI cech o nazwie "attributeValue" (może być nieskończoność wartości, generlanie tez z 10)
id, attributeGroup_id, name
1, 1, Czarny
2, 1, Biały
3, 1, Zielony
4, 2, Mały
5, 2, Duży
Problem mam z stworzeniem tabeli cen gdzie będzie inna cena do każdej kombinacji wartości cech,
Najprostsze rozwiązanie to stowrzenie takiej oto tabelki "price", gdzie w value wstawiam id WARTOŚCI cechy z poprzedniej tabelki
id, price, value1, value2, value3, value4, value5, value6, value7, value8, value9, value10, value11
1, 55, 1, 4, 0, 0, pozostałe same zera (55 zł to koszt Czarnego-Małęgo)
2, 66, 1, 5, 0, 0, pozostałe same zera (66zł to koszt Czarnego-Dużego)
3, 54, 2, 4, 0, 0, pozostałe same zera (54 zł to koszt Białego-Małego)
no i tak dalej, wszystkie kombinacje z wszystkimi
I pomysł jest żeby właśnie wstawiać te id WARTOŚCI pokolei w tabelke z cenami w pola valueX
Tylko nie podoba mi się to bo jak będzie dużo rekordów i dużo kombinacji to system sie zarżnie.
Macie jakiś inny pomysł jak przechowywać ceny wszystkch kombinacji ?
RE: Jaka tabelka do przechowywania cen wszystkich kombinacji cech produktów? - Pedro84 - 25-08-2012
Hej,
na Twoim przykładzie widać, że:
- każdy atrybut może mieć wiele wartości
- każdy produkt może mieć wiele atrybutów
- każdy produkt może mieć wiele cen zależnie od wartości atrybutu.
Są to standardowe relacje many:many. Baza zaprojektowana poprawnie, normalizacja pełną gębą. Bez zastosowania denormalizacji bazy danych, nic innego nie wymyślisz. Tak zwane pivot tables właśnie temu służą: do przechowywania informacji o relacjach m:m.
Kwestia wydajności? Jeśli masz mniej niż 10000 produktów, to na spokojnie tę kwestię olej. Pamiętaj: "premature optimization is a root of all evil".
Możesz oczywiście przechowywać wszystko w tabeli produktów, w postaci zserializowanej, ale:
- każda operacja zmiany: deserializacja, zmiana, serializacja, zapis
- wyświetlenie: deserializacja, wyświetlenie
- wyszukiwanie po takich rekordach jest prawdziwym bólem.
Moim zdaniem, nie ma sensu.