projekt nietypowej bazy danych Opcje

[nowy_pehapowiec]

Mam zrobić bazę danych do małego sklepu internetowego. Ale wymagania są dość nietypowe:

A) Produkty mają być umieszczone w drzewie kategorii, z którego będzie robione menu - proste.

(IMG:style_emoticons/default/cool.gif) System tagów i wyszukiwarka po tagach - proste.

C) Produkty mają być umieszczone w drzewie2 producentów i ich kategorii, z którego będzie robione kolejne menu. Czyli jeśli producent X ma u siebie jakieś produkty w jakiś kategoriach to cały ten schemat ma być odwzorowany w tym moim drzewie2. Czyli poziom 0 to nazwy producentów, poziom 1 to najbardziej ogólne kategorie u danego producenta i tak dalej. Mi się to nie podoba ale ponoć ma to ułatwiać szukanie produktów jeśli wcześniej szukało się ich na stronie jakiegoś producenta. I z tym mam problem. Zrobiłem drugie drzewo i dodawany do bazy produkty trzeba umieścić i w pierwszym drzewie (kategorii) i w drugim (producentów). I jakoś to działa ale pojawił się problem ze ścieżką nawigacyjną (taką w stylu "tu jesteś"). Przy jednym drzewie sprawdzałem id wyświetlanego produktu albo grupy produktów i sprawdzałem w bazie co jest nadrzędne (kilka razy) i dostawałem ścieżkę. Ale teraz jest niejednoznaczność. Jeden produkt występuje w 2 drzewach i w zależności od tego czy został wybrany poprzez nawigowanie po drzewie 1 czy drzewie 2 powianiem wyświetlać różne ścieżki. Ale mam tylko id i nie wiem w które menu kliknął user, żeby otworzyć stronę produktu z tym konkretnym id.

D) Do tego ma dojść jeszcze trzecie drzewo co już zupełnie miesza.

E) Jeszcze odnośnie tagów, chciałbym, żeby po wybraniu wyświetlenia produktów z jakimś tagiem, te produkty wyświetlały się nie jako lista ale właśnie jako jedno z drzew. I tu problem taki, że dodanie do select prostego warunku where nie zadziała po kategorie nie mają dodawanych tagów.

F) Inne sposoby szukania produktów. Co poza pełno tekstowym wyszukiwaniem produktów można dodać? Na razie dodałem wybór tagów z listy.

G) Jeśli pozwolę na dopisywanie tagów przez każdego usera (jedno polowy formularz) to pewnie roboty będą dopisywać śmieci. Jak poza captcha można się zabezpieczyć przed tym.


Może ktoś łaskawie pomógłby mi się uporać z projektem takiej bazy? Byłoby fajowo. Każda dobra rada na wagę złota.

pozdro

[nowy_pehapowiec]

[SQL] pobierz, plaintext 
WHERE
produkt_tag = tag OR rodzic_tag = tag OR rodzic_rodzic_tag = tag i tak dalej
[SQL] pobierz, plaintext 

A nie odwrotnie?

[SQL] pobierz, plaintext 
WHERE
produkt_tag = tag OR dziecko_tag = tag OR dziecko_dziecko_tag = tag i tak dalej
[SQL] pobierz, plaintext 

Drzewo pobieram i wyświetlam od góry. Czyli powonieniem sprawdzać czy tag występuje u jakiegokolwiek dziecka? Czy można to jakoś zrobić bez rekurencji?
Bo pobieranie tagów dziecka i ich sprawdzanie, potem pobieranie tagów dziecka dziecka i ich sprawdzanie masakrycznie zwolni bazę. Jak to zrobić?

E). Wyszukując produkt po tagu, dla każdego odnalezionego musisz pobrać resztę ścieżki w górę, potem wyniki pogrupować od góry, od kategorii najszerszego znaczenia, do tej najzwięźlejszej.

Nie rozumiem. Myślałem, że będę pobierać drzewo od góry. Wtedy właśnie ten problem mi się pojawił z rodzicami nie mającymi tagu dzieci. Jakbym pobierał produkty spełniające tag to nie byłoby tego wcześniejszego problemu. Ale jak je później wyświetlić w postaci drzewa? Zupełnie nie wiem jak się za to zabrać.

D). Po co tyle tych drzew?

Wiem, że to jest głupie ale to nie mój pomysł i nie mogę go zmienić.

C-A). Aby dać sobie możliwość wyświetlenia breadcrumbs'ów musisz jakoś poinformować skrypt z której ścieżki (drzewa) ma korzystać. Bo w takim, że tak to ujmę mętliku sam się nie połapie. Jeśli produkt może podlegać pod ścieżkę producenta->kategorii->subkategorii, lub producenta->tagu, etc, to musisz jakoś przekazać do skryptu gdzie ma tego szukać. Albo możesz co najwyżej pobrać pierwszą pasującą opcję.

Już sobie z tym poradziłem (IMG:style_emoticons/default/smile.gif)

Czy nie możesz ograniczyć tego do drzewa kategorii a producenta umieścić jako jeden z atrybutów (właściwości) produktu?
Przynależność do kategorii może być różna, bo monitor lcd 22" może należeć do głównej kategorii monitory, subkategorii lcs, lub subkategorii 22", anyway producenta ma jednego.

Niestety nie mogę, bo podział w drzewie producentów ma być dokładnie taki jak an stronie danego producenta (każdy ma inny). Kolejny niefunkcjonalny bezsens (IMG:style_emoticons/default/sad.gif)
A tak przez ciekawość, jeśli mam kategorie nierozróżnialne od produktów to czy lepiej dopisywać producenta do tabeli z produktami (wtedy kategorie będą miały NULL w tej kolumnie), czy lepiej stworzyć osobną tabelę z producentami i tabele product-producer? A może wpisać producentów jako tagi? I tylko w dodatkowej tabeli trzymać samą listę producentów (żeby odróżnić od tagów)? Które rozwiązanie uważasz za lepsze?

Jak ja to widzę, właśnie jedno drzewo. Nie stracisz na funkcjonalności, bo nadal będziesz mógł utworzyć drzewko menu według producenta, po prostu stworzysz drzewko po drzewku dla każdego producenta. Tak samo z resztą funkcjonalności, które przedstawiłeś.

Też o tym myślałem, ale nie zależy to teraz ode mnie. Czy dobrze myślę, że wyświetlanie drzewa z podziałem na producentów trzeba byłoby wtedy zrobić tak jak wyświetlanie drzewa produktów posiadających jakiś tag?

Poza tym jest w bazach danych pojęcie redundancji danych. No i robiąc kilka drzewek ze względu na najbardziej ogólny podział łamiesz tą zasadę. Każdy produkt występuje tyle razy ile masz drzewek, pomimo, że jest to ten sam produkt. (chyba, że źle zrozumiałem Twój opis - popraw mnie jeśli się pomyliłem). Drzewka

mają być podobne, różnice marginalne. Wiem, bez sensu (IMG:style_emoticons/default/sad.gif)

W przypadku bazy opartej o drzewie większość działań będzie polegała na chodzeniu po drzewie w tą i z powrotem, niestety nie unikniesz tego.

Z chodzeniem po drzewie od góry do dołu jakoś sobie radzę. Ale w drugą stronę już nie. Jeśli możesz to napisz jak przechodzić po drzewie w górę i potem grupować wyniki, tak, żeby potem znowu otrzymać drzewo?






Zapomniałem się jeszcze zapytać, czy drzewo z bazy lepiej jest pobierać jednym zapytaniem, czy wieloma? Teraz pobieram wieloma zapytaniami. Po kolei wszystkie dzieci jakiegoś rodzica, potem dzieci dzieci. Czyli bardzo dużo pytań SELECT, między którymi wyświetlam listę nieuporządkowaną w html. Czy jeśli szybkość jest nadal na akceptowalnym poziomie, to warto zmienić tą moją metodę? Np pobrać tabelę z drzewem do PHP i później w samym PHP generować z niej odpowiednią strukturę drzewa? Byłoby dużo więcej roboty ale może warto?


pozdro