Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [sql] Cechy produktów - propozycja struktury tabel
Forum PHP.pl > Forum > Bazy danych
Sajrox
Witam,

Jestem teraz na etapie tworzenia struktury tabel cech produktów:

Oto co wymyśliłem:


Krótkie wyjaśnienie tabel:
features_has_categories - łączy daną cechę z daną kategorią (aby przy danej kategorii były dostępne tylko określone cechy)
features - nazwy cech
features_defaults - zserializowana tablica z domyślnymi wartościami dla danej cechy (np. cecha kolor będzie miała tutaj listę kolorów które wyświetlą się w formie listy rozwijanej)
features_values - wartości danych cech (jedna wartość może należeć do kilku produktów, zawarte jest to w tabeli items_has_features_values). Tutaj są 2 rodzaje pola jeden jest dla typu sring drugi dla wartości typu int. Służy to szybszemu wyszukiwaniu danej cechy w bazie (w tym wypadku typu int)
items_has_features_values - mówi która wartośc należy do danego produktu, jedna wartość może być połączona z wieloma produktami (jeden do wielu)
features_units - jednostki dla danej cechy (np: dm, cd, m, km itp...)


Co o tym myślicie ? Troche może skomplikowane ale chce uniknąć powtarzania i ułatwić integracje z wyszukiwarką produktów.
croc
Nie podoba mi się pomysł serializacji w features_defaults.
Sajrox
W sumie nie ma sensu rozbijać tego na pojedyncze krotki. Z tego pola będę tylko korzystać w momencie wyświetlania listy wartości dla danej cechy (w formie listy rozwijanej).
Np. może tam być lista kolorów. W momencie gdy wybiorę kolor 'czerwony' to zostanie on i tak dodany w formie tekstowej do tabeli features_values - pole value_string. No chyba że już taki istnieje to wtedy dodam tylko krotkę łączącą tą wartość z danym produktem (czyli dodaje krotkę tylko do 'items_has_features_values'). Nie chce żeby wartości były powtarzane.

Reasumując sama zserializowana tablica domyślnej listy wartości służy tylko pomocniczo do ograniczenia wpisywanych wartości.
croc
Ale serializując nie dodajesz klucza obcego na wartość i tracisz solidność struktury. Nie wiem na ile duży projekt tworzysz, ale jeśli co najmniej średni, to jednak zdecydowałbym się na pojedyncze rekordy dla wartości domyślnych.
Sajrox
Tak tylko jakie otrzymam korzyści z tego tytułu?
Te dane będą tylko potrzebne do utworzenia pola typu select z listą domyślnych wartości. Nie mam zamiaru ich stosować nigdzie indziej. Czyli klucze obce nie są potrzebne.
croc
Wiesz, tak się mówi. Najlepiej gdy każda relacja jest obdarzona kluczem obcym. Powiem szczerze, że zamiast takiej serializacji ja osobiście wolałbym zrezygnować całkowicie z wartości domyślnych.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.