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

[bww]

Nie wziąłem.

Dodatkowo stworzyłbym tabelki:

PARAMETERS
----------------
id_parameters PK
param_name
--unit (jako wartość np. m2)

TYPE_PARAMETERS
---------------------
id_parameters FK
id_type FK
tutaj kluczem głównym będzie złożenie kluczy obcych

Do tabelki REALESTATES można dodać kolumny, które będą wspólne dla każdego typu nieruchomości np. cena + kolumnę parametrs (o tym za chwilę), do tabeli PARAMETERS można wpisać wszystkie parametry nieruchomości, które są rózne, a w tabelce TYPE_PARAMETERS będzie znajdować się połączenie tabel PARAMETERS i TYPE co spowoduje, że każdemu rodzajowi nieruchomości będzie można określić oddzielny parametr.

W aplikacji np. na ekranie dodawania nowej nieruchomości, wypisałbym wszystkie parametry pasujące do danego typu nieruchomości, a po uzupełnieniu przez użytkownika tworzył tablicę i zapisywał do tabeli REALESTATES (kolumna parameters) korzystając z funkcji serialize().

Ewentualnie stworzyć jeszcze jedną tabele (nazwijmy ją TYPE_PARAM_REALE), która będzie tworzyła relację tabeli REALESTATES i TYPE_PARAMETERS, wtedy funkcja serialize() nie będzie konieczna, bo w tej tabeli dla każdej nieruchomości będzie kilka rekordów z parametrem i jego wartością:

TYPE_PARAM_REALE
---------------------
id_TYPE_PARAMETERS
id_rel
value

id_TYPE_PARAMETERS i id_rel tworzą klucz główny

Realizować można to np. tak:
Pracownik wybiera typ nieruchomości 'mieszkanie', które w naszej tabeli TYPE ma id = 1. Wypisujemy mu parametry jakie są dostępne dla tego typu:

[SQL] pobierz, plaintext 
SELECT id_TYPE_PARAMETERS, param_name FROM parameters p
JOIN type_parameters tp ON p.id_parameters = tp.id_parameters AND tp.id_type = 1
[SQL] pobierz, plaintext 

Pracownik dodaje nową nieruchomość, uzupełnia odpowiednie pola, a w aplikacji wykonują się dwa INSERTY jeden dodający nieruchomość do tabeli REALESTATES, drugi INSERT do tabeli TYPE_PARAM_REALE (id_TYPE_PARAMETERS wyciągnąłeś zapytaniem powyżej, id_rel można wyciągnąć przez mysql_insert_id(), value to wartość wpisana w formularzu).

Może ktoś doświadczony wypowie się jeszcze...