Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Jaka tabelka do przechowywania cen wszystkich kombinacji cech produktów?
#1
Question 
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 ?
Odpowiedz
#2
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.
Dobre samopoczucie w tym tygodniu sponsoruje cytat:
Cytat:Mogę tylko tylko na prawo i lewo ale na środek nie mogę.
Odpowiedz


Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości
Sponsorzy i przyjaciele
SeoHost.pl