15 minut czyli 4 w ciągu godziny i 32 w ciągu dnia
Takie rzeczy raczej ogrywa sie w kodzie a w bazie trzyma sie date(ewentualnie godzine) rozpoczecia i zakonczenia - dlaczego? Dla elastycznosci jak powiedzial wlasnie @Patryk27
Zrobieles trzy strzalki do Wizyty, ale jak chcesz to polaczyc bo ten schemat nie mowi nic o relacji poza jej kierunkiem? Musisz w tej tabeli trzymac 3 ID(lekarza terminu, i pacjenta)...
Teraz kolejny problem z terminami?
- W Twoim wypadku co dziennie rano bedziesz tworzyl wpisy na wizyty na dzisiejszy dzien? Cron, triggery, pani Krysia z recepcji? A co jesli cos pojdzie nie tak i sie nie stworza i pani na recepcji nie bedzie mogla zarezerwowac wizyt?
- Czy to ma byc uniwersalny schemat dla wszystkich dni jednakowy? Jesli tak to dlaczego nie zakodowac tego jako logike biznesowa?
Wedlug mnie tabela terminy powinna zostac zlaczona z Wizytami i zawierac ID, lekarza, pacjeta i date. rozpoczecia i zakonczenia, chyba ze wymaganiem biznesowym jest 4 wizyty na godzine jak w fabryce ( ͡° ͜ʖ ͡°), to wtedy mozesz dac data wizyty i przy tworzenieniu sprawdzac czy wczesniejsza trwa rowno 15 min ewentualnie czy okres miedzy dodawana a poprzednia jest wielokrotnoscia 15.
IdDane w tabeli dane wskazuja na to ze jedne dane moga nalezec do kilku pacjetow... Jesli tak Ok. ale jesli nie Dlaczego po prostu kluczem nie beda Id Osoby?
@MackoSawko dlaczego nie umieszczasz kluczy obcych na schemacie?
Kolejna rzecz:
IdPacjent
IdDane
IdWizyta
Te nazwy wyglada okropnie i sa redudantne i na etapie wdrazania sa uciazliwe.
Piszac zapytanie
SELECT wizyta.IdWizyta, pacjent.IdPacjent FROM wizyta, pacjent WHERE ...
po co sie powtarzac?
SELECT IdWizyta FROM wizyta ... WHERE
Jw wyzej.
Jesli uzyjesz ORMa ktory ma zakodowana nazwe tabeli w jednym miejscu co jest jedna z jego idei aby mozna bylo latwo zmienic nazwe tej tabeli min i aby nie uzywac nazw wlasnych jako stringow w kodzie, jesli zmienisz nazwe tabeli to powodzenia z refaktoryzacja nazw pol w tabeli :)