Dynamiczne cechy produktów w sklepie internetowym.

Witam,
Klepię ostatnio sklep internetowy (nie marudzić, że są miliony innych i mój będzie beznadziejny, ma być własnej produkcji to taki klepię) i myślałem o takiej opcji jak dynamiczne cechy produktów, osobno dla każdej kategorii. Czyli "dyski twarde" mają "pojemność", "rpm", "cache" itd, "telefony komórkowe" mają "rodzielczość ekranu", "przekątną ekranu", "wagę", itd itd. Na początku myślałem po prostu wyświetlać formularzyk na podstawie danych o możliwych cechach i ładować to w JSON i do bazy (do tabeli z produktami), ale interesuje mnie opcja sortowania w/g tych kryteriów (np pojemności dysków). I jak to teraz myślicie zrobić najlepiej? Dodawać pole w tabeli dla każdej cechy? Zapisywać cechy w innej tabeli (przykład poniżej) i potem wybierać je jakoś magicznie (da się tak, żeby to od razu sortować przy zapytaniu?) - w tym przypadku jest też sprawa wydajności.
przykład tabeli z cechami:

moim zdaniem twoja wypowiedź źle świadczy o Twojej znajomości zagadnień bazodanowych, a dodatkowo podważasz profesjonalizm osób opracowujących strony internetowe.

No tak, nie jestem mistrzem baz danych, dlatego pytam jak rozwiązać konkretny problem. Coś nie tak?

Gdzie "podważam profesjonalizm osób opracowujących strony internetowe"? I co konkretnie robią te osoby?

Nie wiem dlaczego zamiast odpowiedzieć czepiasz się nie wiem czego, co najmniej jakbym zgrywał nie wiadomo jakiego profesjonalistę z 10 letnim stażem?

to ci napisać krok po kroku twoją bazkę?

Realizowalem juz cos podobnego. Obecnie podobna funkcjonalnosc wykorzystywana jest w projekcie Coyote CMF, obslugujacym 4programmers.net.

Co prawda nie bylo to w sklepie internetowym, lecz w systemie zarzadzania biurami nieruchomosci. Admin mogl z poziomu panelu administracyjnego dodawac nowe pola, charakteryzujace - np. "Domy", "Mieszkania", czy "Dzialki". Wyglada to tak, ze w panelu user wybiera sobie komponent (combo, checkbox, radio, textarea itp itd), jego nazwe, walidator, filter (czy ma byc pole obowiazkowe, liczbowe, tekstowe itp itd). Nastepnie takie pola sa wyswietlane w formularzu i zapisywane do bazy. Ale do rzeczy.

Mamy tabele component:

Tabela field:

Tabela field_item (jezeli pole jest komponentem typu <select> ta tabela zawiera opcje to wyboru)

W Coyote CMF jest jeszcze field_filter, field_option, ale nie chce mi sie tyle pisac :P Zajrzy do zrodel ;)

Potrzebujesz jeszcze tabeli field_data, gdzie bedziesz skladowal dane:

To tak mniej wiecej :)

od Ciebie konkretnie oczekiwałbym żebyś nie podpisywał w tym temacie, wystarczy.

zadałem pytanie, bo mam problem z ideą w jaki sposób przechowywać dane, podałem dwa (albo trzy jeżeli liczymy tego jsona którego odrzuciłem) przykłady, pytam który lepszy bądź o jakąś wskazówkę jeżeli moje myślenie zmierza zupełnie w złym kierunku. jeżeli jest taka możliwość to jakiś prosty przykład tabeli. tyle. potem sobie to przemyślę, napiszę i zapamiętam na przyszłość.

dzięki Adam, mam za to małe "ale" :)

otóż, podobną rzecz wykminiłem 2 dni temu do czegoś innego, tabele praktycznie to samo, tylko nazwy inne, i inaczej zrobione to z selectem (mozliwe opcje mam zapisane w kolumnie z typem danych (checkbox itd) - rozdzielam je jakims znakiem. proste to są opcje wiec tak jest ok).

tylko, że wciąż moim problemem jest - jak teraz wybrać te dane z tabeli, z możliwością ich sortowania.
wybrać przedmiot+atrybuty = spoko, ale wybrać wiele przedmiotów, sortując wg takiego atrybutu - to już nie mam idei.

Nie potrzebujesz żadnych ideii. JOIN i ORDER BY stanowczo wystarczą.

Czy ja wiem?
Tabela produkty (p)

Tabela atrybuty (a)

I zapytanie z JOIN:

SELECT a . * , p . * 
FROM `p` 
LEFT JOIN a ON p.id = a.idp

No i?
Może coś ze mną nie tak (bardzo możliwe :P), ale ja tu nie widzę sposobu na łatwe wysortowanie tego np najpierw rosnąco wg pojemności (pomijam to, że pole jest tekstowe), potem wg koloru, wybierając oczywiście wszystkie produkty naraz. W jednym zapytaniu.

@dzek69: niestety stosujac takie rozwiazanie i chcac sortowac dane po pewnych kolumnach, musialem czesc logiki aplikacji przerzucic na aplikacje, ktora pobierala dane, laczyla w ladna tablice i zwracala dane.

czyli jednak, no, to tyle chciałem wiedzieć :)

dzięki

 
  SELECT p . * -- i co tam jeszcze sobie chcesz
  FROM `p` 
  LEFT JOIN a capacity ON (capacity.id = a.idp) AND (capacity.name = 'capacity')
  LEFT JOIN a color ON (color.id = a.idp) AND (color.name = 'color')
  ORDER BY capacity.val, color.val

No i jeśli w bazie masz trzymasz rozmiar w postaci tekstowej (np '40 GB', '200 GB') to proponowal bym w tym wypadku zmodyfikowac ORDER BY na cos takiego: ORDER BY len(capacity.val), capacity.val ... itd.

Pozdrawiam.

Takie rozwiazanie jest rozwiazaniem statycznym, niepraktycznym na dluzsza mete. Ale oczywiscie jezeli autorowi to wystarcza - to ok!

Jednak co wowczas jezeli cech produktu bedzie 20? 20x LEFT JOIN?

Adam Boduch napisał(a)

Jednak co wowczas jezeli cech produktu bedzie 20? 20x LEFT JOIN?

No jak będzie chciał sortować po 20 polach to co zrobić. Można jeszcze robić podzapytania na liście pól i po nich sortować, ale z dwojga złego to już lepsze chyba te leftjoin'y.

b

// dopisane

A co do statyczności, to ja oczywiście zakładam, że JOIN'y są robione dynamicznie, wtedy kiedy są potrzebne.

b

Ale nie chodzi tutaj o sortowanie, a jedynie wyswietlenie :) Po prostu chce wyswietlic wszystkie produkty z kategorii "RTV" i zaprezentowac je w formie tabeli i ewentualnie sortowac, ale po jednej kolumnie.

Jezeli sprzet RTV bedzie opisywany 10 kolumnami, to takie zapytanie skladajace sie z min 10 LEFT JOINow bedzie .... hmm.... "nieeleganckie". No, ale jak kto woli...