Jaki schemat BD w MySQL?

[flavio100]

Witam wszystkich,

PROSZE O ODPOWIEDZI TYLKO OSOBY KTORE SIE ZNAJA (minimum 3 lata doswiadczenia z BD).

mam pytanie odnosnie schematu bazy danych, problem jest tego typu, że:

(ten sam problem wytlumacze na przykladzie BD ogloszen samochodowych)

1) mam tabele SAMOCHODY w ktorej chce pamietac dane o ogloszeniu

chciałbym też pamiętać jego wyposazenie, tj. czy ma ABS i ELEKTRYCZNE SZYBE (ESZ).

i teraz: czy lepiej jest zrobic tablele SAMOCHODY z atrybutami (ABS, ESZ) i jesli ma to wyposazenie to ustawiac np. ABS na 1 a jesl nie ma to na 0. (czyli pamietamy co dany samochod MA a czego NIE MA).

CZY

zrobic 2 tabele i intersekcję, tj. tabela SAMOCHODY oraz tabela WYPOSAZENIE i relacja wiele do wielu (czyli intersekcja z pamietanymi kluczami- co dany samochod MA).

Kazde rozwiazanie ma swoje plusy i minusy, baza danych niewielka (około 100 000 rekordów).

jak sądzicie? prosze o jakikolwiek argument:)

[Mion]

W dużym stopniu zależy to od tego czy dodatkowe parametry mają być uwzględniane w kryteriach wyszukiwaniu czy tylko prezentowane na stronie danego pojazdu.

[flavio100]

W dużym stopniu zależy to od tego czy dodatkowe parametry mają być uwzględniane w kryteriach wyszukiwaniu czy tylko prezentowane na stronie danego pojazdu.

mają być uwzględniane przy wyszukiwaniu, np. pokaż wszystkie ktore maja ABs, albo ABS i ESZ.

wyszukiwanie po slowash "abs" nie jest konieczne.

[Mion]

No to jest kolejne pytanie czy wyszukiwanie z dodatkowymi parametrami ma być typu AND czy OR. Tak, czy inaczej jest co najmniej kilka sposobów implementacji tego typu funkcjonalności.

[flavio100]

No to jest kolejne pytanie czy wyszukiwanie z dodatkowymi parametrami ma być typu AND czy OR. Tak, czy inaczej jest co najmniej kilka sposobów implementacji tego typu funkcjonalności.

AND

jasne ze jest co najmniej kilka w zasadzie wszytko jedno jak się to zrobi i ogolnie nie wymaga to jakiegos dluzszego zastanawiania sie, raczejintersuje mnie jak inni by na taki problem spojrzeli i jakie rozwiazanie by wybrali.

wiec?

[Mion]

@w zasadzie wszytko jedno jak się to zrobi i ogolnie nie wymaga to jakiegos dluzszego zastanawiania sie,

Skoro tak uważasz to po co zadajesz w ogóle pytanie jak według ciebie nie ma się nad czym zastanawiać, bo ja uważam, że właśnie jest nad czym.

[flavio100]

@w zasadzie wszytko jedno jak się to zrobi i ogolnie nie wymaga to jakiegos dluzszego zastanawiania sie,

Skoro tak uważasz to po co zadajesz w ogóle pytanie jak według ciebie nie ma się nad czym zastanawiać, bo ja uważam, że właśnie jest nad czym.

jesli chciabym to po prostu zrealizowac to nie ma nad czym sie zastanawiac - dla konkretnego zastosowania ,

z mała liczba zapytan, z przeznaczeniem dla kilku userow w zasadzie nie ma roznicy, wszak chcialbym jednak zrobic to porządnie.

Testy obciazeniowe wyszly bardzo podobnie dla obu struktur (przy danych testowych w liczbie 90 000 krotek), podobnie jak czas odpowiedzi (0.014sek do 0.018sek z przewaga dla modelu bez intersekcji). - dla zapytan prostych:

(auto_wyp to intersekcja z kluczami z wyposazenia oraz auto)

SELECT * FROM auto, wyposazenie, auto_wyp where auto.id=auto_wyp.id_auto and auto_wyp.id_wyp = wyposazenie.id AND wyposazenie.nazwa='abs'

oraz

select * from auto where abs='1'

dla innych zapytan (z rozna iloscia Orow i Andow) jest z przewaga modelu bez intersekcji juz na poziomie 45%, a wiec prawie 2 razy krotsze.

Z drugiej strony jak dojdzie nowy atrybut (np. tempomat czy dach panoramiczny) to trzeba bedzie ingerowac w strukture tabeli AUTO zamiast dodac po prostu krotke z nazwa "dach panoramiczny" w tabeli WYPOSAZENIE.

?

Pomysły?

[flavio100]

jakby ktos był ciekawy to wybralem wersję z intersekcją ze względu na brak koniecznosci pamietania danych, ktorych nie musimy pamietac (czyli nie musimy pamietac, ze dany samochod NIE MA elektrycznych szyb - pamietamy tylko to wyposazenie, ktore faktycznie MA) oraz ze wzgledow wydajnosciowych po testach na wiekszej liczbie krotek. Dodatkowo w przypadku, gdy doszłoby wyposazenie dodatkowe wystarczy dodac krotke w tabeli WYPOSAZENIE.

Pzdr