Baza danych i dane opcjonalne, Jak prawidlowo utworzyc obiekty w bazie danych Opcje

[Orzeszekk]

Witam. Struktura którą chce zamodelowac jest następująca.

Jest to profil uzytkownika bedacy jednoczesnie profilem firmy korzystajacej z tego portalu.

Profil ma przechowywac informacje o firmie, o danych logowania, oraz o specyficznych informacjach ktore sa wymagane tylko dla firm bedacych inventorami (dającymi pomysly), oraz o specyficznych informacjach firm bedacych inwestorami (bulą za pomysły).

Wymyslilem zeby ta strukture podzielic na 4 tabele.

Jedna tabela to tabela profili uzytkownikow - jest ona wbudowana we framework i przechowuje tkaie informacje jak login, haslo, email, ID w systemie.

Druga tabela to profil firmy - te dane ktore sa wymagane dla absolutnie kazdej firmy ktora chce funkcjonowac.
Kluczem głównym tabeli bedzie ID ktore bedzie takie samo jak ID profilu w systemie. Czyli relacja 1:1

Trzecia tabela to dane specyficzne dla inwestorów (nie wszystkei firmy chca byc inwestorami, jesli firma chce byc inwestorem, to wypelnia kilka formularzy, tworze jej wpis w tej tabeli i juz moze inwestowac), klucz glowny to ID profilu w systemie. Czyli relacja 1:1 opcjonalna, bo tego profilu moze nie byc wcale i wtedy oznacza to ze firma nie jest inwestorem.

Czwarta tabela to dane specyficzne dla pomyslodawcow(inwentorow), tak samo jak w poprzedniej tabeli tylko dla inwentorow.



Natomiast moj kolega z ktorym robie ten projekt twierdzi ze trzeba wszystko (poza profilem uzytkownika, ktory jest wbudowany we framework, czyli username, haslo, email) wrzucic do jednej tabeli a pola zrobic jako nullable. Ja uwazam ze on nie ma racji, bo gdybysmy mieli 15 mozliwosci a nie 2, to byloby w bazie danych za duzo nullów, i za duzo zbednych danych przy selectach poprzez ORM.
Gdyby wszystko co jest choc troche zwiazane z jakas encja wrzucac do jednej tabeli, to relacje 1:1 nie mialy by w ogole racji bytu? Chyba po to one są by dzielic dane miedzy tabelami.

Kto ma racje? ktore podejscie jest prawidlowe? nie chodzi tu o glupie przepychanki kto byl madrzejszy, po prostu chce wiedziec co bedzie lepiej dzialalo i bedzie bardziej poprawne semantycznie. Dlatego prosilbym o odpowiedz osoby ktore mają dobrą wiedze z inzynieri oprogramowania.

Ten post edytował Orzeszekk 12.03.2012, 00:44:01

[Orzeszekk]

ormem bedzie entity framework (ado.net), no ale to prawie jak doctrine.


firma moze byc naraz inventorem i investorem, dlatego mysle doczytywac tą porcje danych jako dodatkowy obiekt
pseudokod w php

czesc inventora
$firma->getInventorData()->getCostam // getinventordata odczytuje encje firma_inventor o ID obiektu $firma
czesc investora
$firma->getInvestorData()->getCostam

zwykle pole z tabeli firma
$firma->getFirmName();

dotychczas mialem wlasny orm i takie rozwiazania sie sprawdzaly, zobaczymy jak to sie powinno prawidlowo robic w profesjonalnych ormach