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.

Jeżeli mówimy o ORM to na przykładzie doctrine najlepszym rozwiązaniem byłoby jednak podzielenie tego na conajmniej 3 tabele z czego:

1. Zawiera dane użytkownika (profilu) plus dane wspólne dla obu typów firm (na przykład adres itp.)
2. Tabela danych szczegółowych dla inventorów
3. Tabela danych szczegółowych dla inwestorów

I teraz mając takie 3 tabele można to zamodelować tak że będziemy mieli 3 encje. Odpowiednio dla każdej tabelki po jednej przy czym, dla tabli 2 i 3 zastosowałbym dziedziczenie (inheritance) z tabeli 1. W ten sposób w obrębie aplikacji można używać jedynie dwóch encji. Encji dla inventora i encji dla inwestora. Dziedziczyć one będą po danych uzytkownika (da się to zrobić właśnie poprzez relację 1:1). W razie wyższej konieczności dla poprawienia wydajności a raczej mniejszej ilości danych pobranych z bazy można używać encji profilowej.

Ogólnie. Zapoznaj się z normalizacją baz danych, poczytaj o tym jak tabele powinny być podzielone chociażby tutaj. To Ci też troszkę odpowie na pytanie jak to powinno wyglądać.

Zawsze należy pamiętać o tym, żeby nie powtarzać tych samych struktur tam gdzie jest to niepotrzebne.

Jeśli te dane ogólne o firmach to dużo pól można tabelkę 1 podzielić na dwie 1a i 1b wg założenia jakie sam podałeś - lecz to zależy już konkretnie do tego jakie tam masz mieć dane i jak będziesz chciał je używać.

W przypadku gdy dane typy firm (inwestor a inwentor) różnią się znacznie - powinien być podział zaproponowany przez Ciebie natomiast gdy różnica polega w zasadzie na zaznaczeniu tego czy dana firma jest typu inwentora czy inwestora - w celu odróżnienia - to nie powinno się tego rozdzielać i należy trzymać w jednej tabeli.

Dobrym nawykiem jest wyciaganie zawsze wspólnej części typów do jednej tabeli i tworzenie tabel dodatkowych dla konkretnych typów gdzie pola się już nie powtarzają na przykład jeśli masz firmę to dodatkowa tabela inwestor_data może przechowywać pole kwota_inwestycji a tabela inwentor_data pole planowany_zysk itd...

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

To nijak nie możesz zrobić relacji 1:1 tak jak pisałeś w pierwszym poście.