Cześć mam problem mianowicie nie wiem który schemat bazy danych będzie lepszy.
Mianowicie tworzę aplikację do zarządzania przychodnią lekarską, w tabeli Visit będę przechowywał
informacje na temat wizyty data,godzina,id pacjenta oraz id lekarza. W tym miejscu pojawia się dylemat nie wiem w jaki sposób przedstawić
lekarza, jako dodatkowa tabela czy jako zwykły user z przydzielonymi rolami lekarza.
Poniżej wstawiam poglądowo diagramy.
0
0
To zależy... IMO pierwszy model zakłada, że każdy lekarz to uzytkownik systemu, co w sytuacji jak będziesz miał lekarza który nie będzie użytkownikiem?
Drugi model trochę lepszy, ale dałbym FK do tabeli lekarzey, userid to daje elastyczność. Generalnie odseparowalbym użytkowników od lekarzy, bo co jak dojdą np. psycholodzy, fizjoterapeuci itd ?
1
Ja bym zrobił jeszcze inaczej to znaczy: miałbym techniczną tabele users gdzie trzymałbym dane do logowania, odzyskiwania hasła, uprawnień (role) itp. oraz 2 kolejne tabele patients i doctors. Jeżeli potrzebna była by część wspólna to dałbym extra tabelę personal_info dla trzymania danych typu imie, nazwisko pesel. Z perspektywy security wolałbym jednak odizolować całkowicie dane lekarzy i pacjentów - przynajmniej tak mi podpowiada intuicja.
Zamiast modelować na poziomie bazy, warto najpierw zamodelować za pomocą boxów na tablicy (UML to już niemodne słowo) na nieco wyższym poziomie abstrakcji. Zastanowić się nad przypadkami: co jak lekarz będzie pacjentem? Oraz na podstawowymi use-case'ami systemu: typu rezerwacja wizyty, dodanie pacjenta, dodanie lekarza, anulowanie wizyty, potwierdzenie i przeprowadzenie wizyty. Jak dane extra musimy przechowywać dla pacjenta (docu medyczna), a jakie dla lekarza (specjalizacja). Jak będziemy obsługiwać abonament medyczny itp.
Do tego warto dodać use-casey związane z samą aplikacją: typu listowanie wizyt u lekarza i pacjenta. Historia wizyt. Zalecenia itp.
Nawet jeżeli jest to zadanie uczelniane, można puścić wodze fantazji i pomyśleć jak by to było w rzeczywistości, tak w ramach treningu...
0
@0xmarcin: Generalnie zakładam że będą wiecej niż 2 role(tj. lekarz, pacjent) co w takim przypadku?
0
@aje123: Jak widać z powyższych postów technicznych moliwości jest mnogość. Aby wybrać najlepszą trzeba - wg mnie - zastanowić się jaki jest cel ? Innymi słowy czym różni się encja 'lekarz' od 'pacjenta' ? Oczywiście na poziomie bazy danych czyli jakie dane o lekarzu chcesz/potrzebujesz przetrzymywać w bazie, a jakie o pacjencie. Jeśli to te same dane to trzymałbym w jednej tabeli, a dla uproszczenia SQL i czytelności aplikacji stworzyłbym view zwracające tylko lekarzy. Wg mnie znacznie czytelniejszy jest SQL: 'select * from lekarze' niż 'select * from użytkownicy where role='lekarz'' lub '... where role=1'.
Co do security - konta, hasła, role, wygasanie haseł, itp - nie widzę powodów aby dublować funkcjonalność bazy danych w aplikacji. Każda baza danych świetnie zarządza bezpieczeństwem. Po to jest stworzona - aby zabezpieczać dane. Po co pisać to od nowa ? Nie lepiej skupić się na funkcjonalności aplikacji ?