Projekt bazy danych Opcje

[symonides]

Cześć,
mam do zaprojektowania bazę danych, która będzie tyczyła się nieruchomości, czyli np. domy, mieszkania, działki. Każdy z tych typów nieruchomości ma jakąś część danych wspólną, np. kraj, województwo, miasto, cenę, itp. Czyli to by była tabela główna o przykładowej nazwie realestates. Co dalej ? Każdy następny typ to kolejna tabela (czyli osobna na dodatkowe informacje o mieszkaniach, domach, czy działek)? Wydaje mi się to troszkę niewygodne, bo gdy dojdzie kolejny typ, np. magazyny to trzeba dodać kolejną tabelę + oczywiście jakieś zmiany w kodzie. Drugi pomysł to prócz tabeli realestates, tabela details, która będzie przechowywać wszystko to co miało być w tych dodatkowych tabelach (np. kolumna media - tylko działki, piwnica - tylko mieszkania, itd. w jednej tabeli).

Dodam, że operacje będą wykonywane na kilku/kilkunastu tysiącach rekordów.

Który pomysł jest waszym zdaniem lepszy? Może macie jakieś propozycje?

Pozdrawiam

[symonides]

W sumie to może być wiele kodów pocztowych do jednego miasta (IMG:style_emoticons/default/smile.gif) http://kodypocztowe.com/miasta-kody-poczto...o/warszawa.html

To teraz tak, w tabeli customers mamy id miasta (town_id). Połączenie kodów pocztowych z miastami - relacja n:m. Jeżeli podanie kodu pocztowego będzie wymagane (jeszcze tego nie wiem), to żeby znać miasto, województwo, itd. to kolumnę town_id w tabeli customers można zamienić na postcode_id. Co do ulic to w sumie nie najgorszy pomysł żeby trzymać je bezpośrednio w tabeli customers/realestates, ale warto też zwrócić uwagę, że konkretne ulice przypadają pod jakiś kod pocztowy. Troszkę tego jest. Nie bardzo jeszcze wiem jak bardzo szczegółowe informacje będą wymagane, dlatego też rozpatruje różne mozliwości jak to zrobić.

[bww]

W sumie to może być wiele kodów pocztowych do jednego miasta (IMG:style_emoticons/default/smile.gif) http://kodypocztowe.com/miasta-kody-poczto...o/warszawa.html

No tak, mieszkałem w małym mieście i przyzwyczaiłem się do jednego kodu (IMG:style_emoticons/default/smile.gif) .

To teraz tak, w tabeli customers mamy id miasta (town_id). Połączenie kodów pocztowych z miastami - relacja n:m. Jeżeli podanie kodu pocztowego będzie wymagane (jeszcze tego nie wiem), to żeby znać miasto, województwo, itd. to kolumnę town_id w tabeli customers można zamienić na postcode_id. Co do ulic to w sumie nie najgorszy pomysł żeby trzymać je bezpośrednio w tabeli customers/realestates, ale warto też zwrócić uwagę, że konkretne ulice przypadają pod jakiś kod pocztowy. Troszkę tego jest. Nie bardzo jeszcze wiem jak bardzo szczegółowe informacje będą wymagane, dlatego też rozpatruje różne mozliwości jak to zrobić.

Czyli w zasadzie kod pocztowy wiąże się z ulicą i być może numerem domu, a nie z miastem. To znacznie utrudnia sprawę. Szkoda chyba czasu na szukanie i analizę, szczególnie gdy aplikacja ma dotyczyć wielu krajów.
Najgorsze z tego wszystkiego to uzupełnianie słowników. Jeżeli nie masz przyzwoitej listy to ciężko będzie to zrealizować.

Pewnie lepiej będzie w aplikacji zostawić użytkownikowi pola (miasto, kod_pocztowy, ulica) do ręcznego uzupełnienia, skryptem Java autouzupełniać w przypadku, gdy np. dane miasto istnieje już w bazie, a gdy nie dodawać do bazy.

Kwestia jak wielka ma być aplikacja, ile nieruchomości będzie się w niej znajdować. Na wielkości rzędu 1 - 10k pewnie nie będzie się opłacać tak kombinować, a użytkownik nie odczuje dyskomfortu uzupełniając ręcznie pole adres (wraz z kodem pocztowym i miastem).

Najważniejsze to wziąć ołówek, dużą kartkę i wszystko sobie rozrysować (tabele, relacje, kolumny, wymagane dane, dane opcjonalne, orientacyjna liczba rekordów w danej tabeli itd.). Bez dobrego projektu, ciężko stworzyć dobrą aplikację.