Baza produktów sklepu internetowego Opcje

[croc]

Witajcie,

tak się zastanawiam jak najlepiej jest zorganizować strukturę bazy danych produktów dla systemu podobnego do Allegro czy eBay. Chodzi o właściwości produktów charakterystyczne dla danej kategorii.

Przykład
Kategoria TELEWIZORY - przekątna ekranu
Kategoria BUTY - rozmiar, kolor, materiał
Kategoria GRY KOMPUTEROWE - gatunek, ograniczenia wiekowe, rok wydania
itp.

Mam dwa pomysły:

1. Osobne tabele dla zestawu właściwości w kategorii
2. Tabela PROPERTIES zawierająca nazwę właściwości i odpowiadającą jej kategorię (skłaniam się ku temu)

Dla obu pomysłów musiałaby powstać tabela PROPERTIES_VALUES, która zawierałaby możliwe wartości.

Pytania do Was:

1. Który pomysł wydaje Wam się leszy, a może macie jakiś inny?
2. Jak rozwiązać kwestię typu danych dla PROPERTIES_VALUES? Czasem będą to daty, czasem napisy, czasem liczby. Umieszczanie wszystkiego w tej samej kolumnie (pewnie wybrałbym varchar) nie wydaje mi się zbyt rozsądne...

[blooregard]

Podobny problem rozwiązuję w następujący sposób:

1. tabela PROPERTIES
W tej tabeli zapisywane są tzw. właściwości w postaci nazwy, jakiegoś krótkiego opisu, jednostki miary itp.

2. tabela CATEGORIES
tabela z kategoriami produktów (nazwa kategorii, opis)

3. tabela PRODUCTS
tabela z produktami (nazwa, opis)

Proces tworzenia asortymentu przebiega następująco (podam na przykładzie książek):
- tworzona jest kategoria w tabeli CATEGORIES ("książki")
- w tabeli PROPERTIES tworzone są właściwości: "ilość stron", "okładka", "ISBN", "data wydania" itp.
- w tabeli łączącej PROPERTIES_TO_CATEGORIES stworzone właściwości przypisywane są do kategorii "książki" (oczywiście mogą być wykorzystane w każdej innej kategorii, w której są potrzebne)

- dodajemy produkt w tabeli PRODUCTS - książkę "Jakaś tam książka"
- w tabeli łączącej PRODUCT_TO_CATEGORY przypisujemy ją do kategorii "książki"
- dzięki relacjom w tabelach PRODUCT_TO_CATEGORY oraz PROPERTIES_TO_CATEGORIES możemy w łatwy sposób ustalić, że produkty z kategorii "książki" mogą mieć takie cechy, jak ilość stron, numer ISBN, autora itp.
- ostatnim krokiem jest zapisanie wartości tych cech w ostatniej tabeli łączącej: VALUE_TO_PROPERTY, gdzie każdy rekord tabeli zawiera: id, id produktu, id cechy (właściwości) oraz jej wartość dla konkretnego produktu.

Co daje taki system:

- całkowitą elastyczność w zakresie przypisywania cech/właściwości do produktów niezależnie od ich rodzaju - przykładowo: chcemy dodać nową kategorię - płyty CD; tworzymy właściwości, takie jak czas nagrania, producent, wykonawca itp. "podpinając" je pod kategorię produktów "płyty CD". Automatycznie WSZYSTKIE produkty z tej kategorii umożliwią przechowywanie informacji o takich rzeczach, jak ich czas odtwarzania czy wykonawca
- aby wyświetlić dane na temat produktu, wystarczy iteracyjnie pobrać z tabeli VALUE_TO_PROPERTY te wartości, które odpowiadają ID produktu, odpowiednimi relacjami dołączając sobie informacje na temat samego produktu, kategorii, nazw i jednostek miary właściwości itp.
- jedna cecha może być wykorzystana w dowolnej ilości kategorii (np. waga, szerokość, kolor), równocześnie można tworzyć cechy właściwe dla bardzo wąskiej grupy produktów bez konieczności powielania danych (np. prąd rozruchowy dla kategorii "Akumulatory samochodowe" - wartość niespotykana w innych produktach)
- dodawać produkt do wielu kategorii posiadających różny zestaw cech/właściwości
- w przypadku pojawienia się nowej cechy/właściwości w bardzo prosty sposób można uzupełnić dane na jej temat dla produktów do niej przypisanych - wystarczy utworzyć taką właściwość, a następnie przypisać ją do tej kategorii (automatycznie wszystkie produktu z tej kategorii uzyskają możliwość ustawienia wartości dla tej cechy i prezentacji jej userowi)

Powód edycji: [blooregard]:

[croc]

Dziękuję za odpowiedź. Ta idea również mi wydaje się świetna, pokrywa się z punktem 2. Co jednak z typami danych? Czasem fajnie byłoby przechowywać wartości w postaci daty czy liczby, choć varchar oczywiście zda egzamin. Nie jest jednak zbyt dużym marnotrawstwem zapisywać liczbę w varchar?

[blooregard]

Dziękuję za odpowiedź. Ta idea również mi wydaje się świetna, pokrywa się z punktem 2. Co jednak z typami danych? Czasem fajnie byłoby przechowywać wartości w postaci daty czy liczby, choć varchar oczywiście zda egzamin. Nie jest jednak zbyt dużym marnotrawstwem zapisywać liczbę w varchar?

No jest to cena, którą trzeba zapłacić za elastyczność takiego systemu. Ewentualnie można rozważyć podział cech na takie, które mają wartości wyrażane liczbowo (waga, rozmiar itp.) czy tekstowo i zapisywać je do osobnych tabel w bazie (np. NUMBER_PROPERTY, TEXT_PROPERTY itp.)

[croc]

Też się nad takim rozwiązaniem zastanawiałem. Może to by nie było wcale takie głupie rozwiązanie? Można by w modelach kategorii podawać poszczególne właściwości razem z typem i może od razu zwracać obiekt. Przy okazji wyszukiwanie odbywałoby się nieco szybciej. Jednak nie byłoby to już tak elastyczne i eleganckie rozwiązanie. Co myślicie?