struktura bazy danych dla serwisu ogloszeniowego Opcje

[merk]

Witam,

jaką strukturę bazy danych zaproponowalibyście do serwisu ogłoszeniowego z
dużą ilością kategorii np osobowe, motocykle, cześci, cieżarowe, przyczepy, maszyny budowlane itd
(w sumie ok 20 kategorii, pozniej pewnie dojda nowe)

ogłoszenie w każdej z kategorii musi być dosyć ściśle zdefiniowane np:

osobowe: marka, model, przebieg, kolor itd
przyczepy: marka, model, wysokosc, szerokosc, dlugosc, ladownosc itd
maszyny budowlane (np: dźwigi i żurawie): marka, model, udźwig, przebieg (motogodziny) itd

czy dla każdej z kategorii tworzyc dedykowana tabele z roznymi kolumnami,

czy tez moze potworek w rodzaju:

np: trzy tabele
ogloszenie - id, data i inne wspólne pola
parametr - id|id_ogloszenie|id_parametr_definicja|wartosc_int|wartosc_float|wartosc_string
parametr_definicja - id|nazwa|opis

struktura powinna byc zoptymalizowana (lub chociaz udawac optymalizacje) pod szybkosc wyszukiwania ogloszen, jednak rozszezalnosc
struktury tez ma znacznie (dodanie / usuniecie parametru, czy tez calkowite przedefinowanie kategorii)

acha, jesli ma znaczenie to serwerem bazy bedzie mssql

[wry]

jesli nie bedziesz tworzyl drzewa kategorii to moze tak:

tabela kategorie:
id - int,
nazwa - varchar

tabela atrybuty:
id - int,
nazwa_atrybutu - varchar,
wartosc_arybutu - varchar,
kategoria_id - int

masz wiazanie jeden do wielu; jedna kategoria moze miec wiele atrybutow, kategoria_id jest kluczem obcym id z tabeli kategorii, jesli chcesz trzymac kazda kategorie w osobnych tabelach to musialbys tworzyc nowa tabele przy dodaniu nowej kategorii do tego reczeni aktualizowac spis tabel zawierajacych kategorie, a komplikacje pojawiaja sie juz przy wyswietleniu wszytskich kategorii,
jesli chcesz tworzyc zagnierzdzone drzewa kategorii zagladnij tutaj

http://dev.mysql.com/tech-resources/articl...hical-data.html

Ten post edytował wry 25.09.2009, 11:16:12

[deirathe]

kategorie:
[id, nazwa, rodzic, slug]
uzytkownicy
[id,imie,nazwisko itd...]
tematy
[id,kategorie_id,slug,opis,tytul,rozwiniecie,uzytkownik_id,parametry_id]
obrazki
[id,temat_id,miniatura,pelen,sortowanie]
parametry
[id,parametrschema_id,wartosc,temat_id]
parametrchema
[id,nazwa,typ]


Może mniej więcej coś takiego??

[merk]

hej,
dzięki za odpowiedzi.

struktury przez was zaproponowane, są fajne w zarządzaniu i definiowaniu ogłoszeń,
podobne do tej z "eZ Publish", zwłaszcza propozycja deirathe jest bardzo podobna.

obawiam się jednak, że wyszukiwanie po atrybutach (np po pojemnosci, mocy, roczniku itd) raczej nie bedzie demonem szybkości,

skłaniam się raczej do koncepcji żeby pola po których bedzie sie odbywać wyszukiwanie trzymac w tabelach w kolumnach (w najgorszym wypadku 1 tabela = jedna kategoria główna,
być może dla kilku kategorii bedzie można zdefiniować jedną wspólną tabelę),
a atrybuty potrzebne tylko do wyświetlenia ogłoszenia trzymac w polu tekstowym jako xml, troche to kłopotliwe, jednak cos za cos.

troche ciekawych informacji znalazlem tutaj

PS:
drzewka w sql i rożne takie bardzo dobrze są opisane w książce "Trees and Hierarchies in SQL for Smarties"