25-08-2012, 23:28
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.
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ę.
