Avatar
Jiří Hrdina:17. května 11:03

Ahoj,

prosím pěkně, mohl bych poprosit o radu? :)

V prvni řadě, jedná se o návrh databázi nemocničního managment systému a měl bych pár dotazů.

1.) je ten návrh v pořádku? Co je případně špatně a co by se mělo udělat jinak?
2.) Je nutná ta m : n vazba mezi pacientem a doktorem? Nechali byste jí tam?
3.) Mezi léky/výkonem a účtem je m : n, přemýšlel jsem, že bych přidal asociační entitu "množství", které by vyjadřovalo kolik léku třeba bylo prodáno na ten jeden účet. Je to dobrý nápad, nebo nechat tak jak to je?

Popis: Dolní větev - tam se dá najít, od kdy do kdy byl pacient v nemocnici, kde, na jakém oddělení atd. V horní větvi - pacient - účet atd - tam se zjištuje, kolik nemocnice vydělala na daném pacientovi podle nějakých tabulek pojištoven. Takže tam bude třeba RTG (vyšetření) a lék nějaký a doktor, který to schválil...

Mockrát děkuji za pomoc :)

Editováno 17. května 11:03
 
Odpovědět 17. května 11:03
Avatar
Jiří Hrdina:17. května 11:04

Obrázek:

 
Nahoru Odpovědět 17. května 11:04
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:17. května 13:41

Do tabulky "pacient" bych přidal ID(identity 1,1) jako PK, nikde nevidím vazební tabulky na vazbu M:N (pacient-lékař), nikde nevidím vazbu mezi tabulkami lékař a typ_lékaře...
Tabulka "umístění" nemá žádné FK, které tvoří vazbu na pacienta ani na pokoj

Editováno 17. května 13:42
Nahoru Odpovědět 17. května 13:41
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:17. května 13:45

Tabulka "cena" mi přijde naprosto zbytečná a jak tak na to koukám, celkově mi v těch tabulkách chybí nějaké FK, které by znázorňovaly vazby mezi tabulkami...

Nahoru Odpovědět 17. května 13:45
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:17. května 14:28

Děkuji za reakci. Jedná se o Entitní diagram, nikoli relační diagram, to jsem zapomněl zmínit. Relační diagram sestavím na základě toho, tam dodám ty FK a propojení mezi tabulkami.
Umístění mám definované jakožto kompozitní primární klíč - tj datem a rodným číslem pacienta (což je jeho primární klíč), v relačním diagramu potom umístění bude mít FK pokoj_id.

Cenu tam mám, aby se dalo spočítat, jak moc nemocnice vydělala na daném pacientovi. Co jsem informován, tak dostávají za to prachy, podle toho, co provedou za úkony(vyšetření) a za léky.

 
Nahoru Odpovědět 17. května 14:28
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:17. května 14:33

Cena se může spočítat (když je to potřeba) z jiných tabulek. Mít na to extra tabulku mi přijde zbytečné. Nicméně tam chybí ty vazební tabulky, např. mezi lékařem a pacientem

Nahoru Odpovědět 17. května 14:33
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:17. května 14:45

A jakou vazební tabulku máš na mysli? Jakože pacient_lékař, kde bude pk1, fk1 pacient_rč(id) a pk2,fk2 lékař_id?

 
Nahoru Odpovědět 17. května 14:45
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:17. května 14:47

Tabulku, kde bude ID, ID_pacient, ID_lekar
protože jeden pacient může mít více lékařů a zároveň jeden lékař bude asi mít víc pacientů...

Editováno 17. května 14:47
Nahoru Odpovědět 17. května 14:47
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:17. května 14:51

A hlavně bych do tabulky "Pacient" přidal to ID, protože RČ není zrovna nejlepší "identifikátor" jako primární klíč...
Ne v každé zemi si "hrají" na rodná čísla, někdy se může vyskytnout i duplicita (nemělo by to být, ale stává se)...

Nahoru Odpovědět 17. května 14:51
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:17. května 14:54

Další, co mě při pohledu na diagram napadlo, že bych asi nedával do tabulky lékařů tu položku plat, protože plat se může změnit a jestli se na tu položku bude vázat nějaký výpočet, tak při změně platu nebudou výsledky souhlasit, nehledě k tomu, že nebudeš mít historii vývoje výpočtů...

Nahoru Odpovědět 17. května 14:54
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:17. května 21:32

A jak by jsi změnil tu cenu, aby zároven mohla být zařazena do ceníku, který je platný nějaké časové období? A pokud máme na mysli to samé s těmi vazebními tabulkami, tak by měli být i mezi účtem - lék/léčba?

Díky

 
Nahoru Odpovědět 17. května 21:32
Avatar
patrik.valkovic
Šéfredaktor
Avatar
Odpovídá na Jiří Hrdina
patrik.valkovic:17. května 23:37

Mě příjde divné ta vazba mezi léčbou a cenou. Léčba přece nemá tabulkové hodnoty, aspoň tak si to myslím.
Potom by v ceníku rozhodně měla být cena.
Dále asi nemá smysl v kontextu léčby uvažovat o sumě.
Plat lékaře bych dal mimo, jak už bylo řečeno. Podobně jako ceník - od, do, kolik.
Pacienta bych neidentifikoval ID, to například cizinci vůbec nemají. Klidně tam dej ID.
Také si myslím, že na jenom pokoji může být více pacientů, teď to povoluje pouze jednoho.
Oddělení bych identifikoval pomocí ID, ne jeho názvem.

To je vše co mě tak napadá, parcialitu už se mi kontrolovat nechtělo.

To Michal Štěpánek: tohle není relační návrh, dekompozice N:M vazby a cizí klíče se nepíší.

Nahoru Odpovědět 17. května 23:37
Nikdy neumíme dost na to, abychom se nemohli něco nového naučit.
Avatar
Odpovídá na patrik.valkovic
Michal Štěpánek:18. května 9:20

Trošku jsem nerozuměl této větě:

Pacienta bych neidentifikoval ID, to například cizinci vůbec nemají. Klidně tam dej ID.

Nemělo to být: "Pacienta bych neidentifikoval RČ..."?

Nahoru Odpovědět  +1 18. května 9:20
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 9:32

Já tu tvou tabulku "Cena" chápu jako extra tabulku, kde chceš mít nějaké součty za nějaké výkony, či platby. To mi přijde zbytečné, protože podle mě budeš chtít potom nějaké součty s konkrétními parametry (datum, pacient, lékař, výkon...) a to z této tabulky stejně nevyčteš... Spíš bych udělal nějakou tabulku "výkonů" nebo "prodejů" (dalo by se to asi i sloučit), kde by bylo třeba "kdo", "kdy", "co" a "za kolik" a z této tabulky pak jednoduše vytáhneš potřebné údaje... Položka "cena" samozřejmě patří do ceníku a měla by být vázána na nějaký výkon, nebo nějaké zboží(léky) a v ideálním případě by měla mít nějakou platnost, abys mohl sledovat i jakýsi vývoj cen a mít historii.
Při programování by ses měl na aplikaci vždycky podívat jakoby "od konce". Zjistit, jaká data či údaje by ta appka měla umět vyplivnout a podle toho zjistíš, jaké údaje tam musíš "nacpat"... 8-)

Nahoru Odpovědět 18. května 9:32
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 11:12

Díky :), parcialitu opravím, id přidám k oddělení a k pacientovi. Co se týká té léčby... Dozvěděl jsem se, že nemocnice (V ČR) je placena podle toho, jakou léčbu/výkony se provádějí a také jaké léky nasazují. Podle toho dostávají peníze od pojištovny. Proto mám léčbu spojenou s cenou, protože je to podobný jako s těmi léky si myslím... Co myslíš tím, že by v ceníku měla být cena? Ceník v té tabulce je tvořen cenami platnými dle dat v ceníku. :)

Bohužel úplně stále nechápu, jak to myslíš :( v modelu výše mám účet, kde mám KOMU, KDO, KDY a cenu potom mám přiřazenou k léčbám a lékům. Čili myslíš, jako tuhle celou konstrukci zničit (účet) a udělat KDO, KDY, ZA KOLIK ? a jak do toho dostanu tu cenu za nějaký produkt?

Díky

 
Nahoru Odpovědět 18. května 11:12
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 11:20

V tom tvém diagramu vidím "účet" a tam je jen ID, datum.
Tento typ diagramu jsem si nikdy nedělal, protože pro mě je "nicneříkající". Dělal jsem si jen diagram, kde byly jednotlivé tabulky a konkrétní vazby mezi nimi...

Editováno 18. května 11:22
Nahoru Odpovědět 18. května 11:20
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 11:28

v modelu výše mám účet, kde mám KOMU, KDO, KDY a cenu potom mám přiřazenou k léčbám a lékům.

Pokud nebudeš mít v té tabulce "výkonů" i konkrétní částku, pak nemusíš mít správné výpočty. Když se ti ceníková cena změní, bude se to přepočítávat (pokud to neošetříš složitými konstrukcemi hledání konkrétní ceny) k aktuální ceně a ne k ceně platné v době výkonu.

Nahoru Odpovědět 18. května 11:28
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Jiří Hrdina:18. května 11:36

A myslíš že to je nicneříkající? Návrhy se učím, tak rád přijmu nové rady, jak to udělat lépe.

Ale abych řekl k myšlence toho účtu:
Třeba v nemocnici - vyskočí okénko, kde lékař bude muset vypsat - Pacienta (což bude patient_id FK), Lékaře, co to podepsal (lékař_id FK), datum bude vytvořen automaticky při vytvoření a id bude nějaké originální pro tu "transakci" řekněme. Poté se do toho účtu nahážou všechny léky/léčby, co jsou předepsané - čili tam potom budou nějaké asociační entity mezi účtem a lékem/léčbou, kde bude třeba účet id - 123 lék_id - 1 a v druhé asociační mezi účtem a výkonem bude - účet_id 123 a léčba_id 3 - čili potom ve finále máme účet o nějakém datumu, lékaři, pacientovi, které mu jsou přiřazeno x léků, x výkonů a cenu mají ty jednotlivé výkony přiřazené třeba tou pojištovnou...

PS: Mohl bych tě ještě poprosit, jak by jsi tu entitu "účet" předělal, aby přímo v tom byla ta cena...? :)

Editováno 18. května 11:37
 
Nahoru Odpovědět 18. května 11:36
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 11:49

Čili navrhuješ přidat k entitě Lék/Léčba atribut cena? a jak potom zajistím tu ceníkovou cenu? Jakože Léčba/Lék budou rovnou vázané na ceník?

 
Nahoru Odpovědět 18. května 11:49
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 12:56

Někomu ten diagram může přijít jako užitečný, ovšem já bych z něj nevyčetl v podstatě nic. Pro mě je důležité, abych v tom diagramu viděl jednotlivé vazby mezi tabulkami a jednotlivé položky tabulek včetně PK a FK.
V tabulce "účet" bych já chtěl mít třeba toto:

  • ID
  • Datum
  • ID lékaře
  • ID pacienta
  • ID léku
  • Množství
  • ID činnosti, kterou lékař vykonává
  • Pokud se cena výkonu počítá na hodiny, pak i počet hodin, resp. čas samotného výkonu
  • Cena (bude při ukládání vypočtena podle ceníkových položek)

    možná mě napadne i něco dalšího, co by se tam mohlo hodit, ale tohle mi přijde jako takový základ pro výpočet nějakého výdělku a pro reporty...

Editováno 18. května 12:56
Nahoru Odpovědět 18. května 12:56
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 13:14

Dobře, hodím sem ještě relační diagram.
Mám tam vše, kromě množství a té ceny.

Čili bylo by možná dobré, rozbít m : n vazbu mezi lékem a účtem a dát tam entitu množství? jakožto asociační entitu?
A co s tou cenou? jak jí dostanu do toho účtu?

 
Nahoru Odpovědět 18. května 13:14
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 13:17

V první řadě bych ale zrušil to RČ u pacienta jako identifikátor a dal bych tam ID (identity 1,1), protože u prvního cizince budeš v pytli.

Nahoru Odpovědět 18. května 13:17
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Jiří Hrdina:18. května 13:31

Ok, opravená verze

 
Nahoru Odpovědět 18. května 13:31
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 13:37

a ještě jedna, měl jsem tam ještě blbě ty klíče propojené

 
Nahoru Odpovědět 18. května 13:37
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 13:41

účet_lék a účet_léčba bych zrušil, podle mě jsou k ničemu, protože každý řádek v "účtu" bude reprezentovat záznam jen na jeden lék, či na jeden lék. výkon...
A pořád jsem nějak nepochopil smysl těch tvých tabulek "cena" a "ceník".

Nahoru Odpovědět 18. května 13:41
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 13:50

No, já měl za to, že mezi nimi bude m : n vazba - že účet může mít několik léků a léky mohou být ve více účtech. Nebo to tak není? A nebo místo toho lék_účet by možná šla dát ta entita Množství? nebo přímo do toho účtu?

A jak v tom potom vypočtu tu sumu v tom účtu?

No cena je přiřazena léčbě a lékům podle platného ceníku (OD-DO), aby se potom dalo historicky hledat? Nebo je to špatný přístup? Že se ceny budou měnit podle toho ceníku...

 
Nahoru Odpovědět 18. května 13:50
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 13:54

Jinými slovy, jak pak zajistím, že když řekněme, že na pacientovi budou provedeny DVA výkony a budou me třeba naordinovány 3 léčby (RTG, obvaz, odběr krve), jak to všechno narvu do jednoho účtu, když tam bude jen místo pro jeden?

 
Nahoru Odpovědět 18. května 13:54
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 13:55

Jedna položka v účtu = jedna položka léků nebo výkonu.
Celkovou sumu pak jednoduše sečteš podle zadaných kritérií

Nahoru Odpovědět 18. května 13:55
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 13:56

Pak jedině, že bys měl další tabulku, kde by byly "položky účtu" a v tabulce "účet" by byl jen ID, datum, lékař, pacient a celková suma, možná případně nějaká poznámka.
A tabulka "položky_účtu" by měla jako FK ID_účtu.

Editováno 18. května 13:57
Nahoru Odpovědět 18. května 13:56
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 14:17

Takto myslíš? A jak ted tam dostanu to množství? a jak spočtu tu sumu v účtu?

 
Nahoru Odpovědět 18. května 14:17
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 14:19

V podstatě jo, jen nevím, co všechno máš za položky v tom "položky_účtu. Rozhodně bych tam dal nějaký čas pro výkon, množství konkrétního léku, atd...

Nahoru Odpovědět 18. května 14:19
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:18. května 14:36

Ok děkuji. Čili do toho položky_učtu ještě vložím to množství a čas... a jak ještě spočtu tu cenu z takto uspořádaných tabulek, abych měl v tom suma v účte tu celkovou sumu? Třeba za 5 léků a třeba za léčbu RTG, odběr krve. Jak to tam dostanu ted?

 
Nahoru Odpovědět 18. května 14:36
Avatar
Jiří Hrdina:18. května 14:38

A ještě... v tom Položky_účtu nemůžu mít jako ID účet_ID, protože mi to pak vyhodí duplicate-primary key. Co tam za primární klíč?

 
Nahoru Odpovědět 18. května 14:38
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 14:45

Sumu jednoduše spočítáš z těch položek při ukončování/ukládání toho účtu...
Při ukládání jednotlivých položek zjistíš jednotkovou cenu v ceníku, vynásobíš to počtem kusů/hodin a uložíš cenu za položku (to by měl být další sloupec v tabulce "položky_účtu"). Při ukládání účtu je pak jen sečteš...

Nahoru Odpovědět 18. května 14:45
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:18. května 21:33

V "položky_účtu" bude PK normální ID, účet_ID bude FK

Nahoru Odpovědět 18. května 21:33
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Jiří Hrdina:19. května 11:36

a lze to nějak nastavit tu sumu, abych to viděl automaticky v těch tabulkách? že to tam sql propočítá automaticky? např v mysql? Nebo to až pak zjistím (tu sumu) na základě sql dotazu?

A k tomu položky_účtu - neměly by být FK i Lék, Léčba, Účet? A nešlo by udělat ID ze všech těhle 3? Jakože by byly všichni PK, FK - účet_ID,lék_id, léčba_id ? nebo je lepší tam dát takhle to id prostě?

Díky moc :)

 
Nahoru Odpovědět 19. května 11:36
Avatar
Jiří Hrdina:19. května 13:05
SELECT p.rč, Sum(le.cena_cena) cena_za_léčbu, (Sum(l.cena_cena*pu.množství_léku)) cena_za_léky FROM Pacient p
JOIN účet u
ON p.rč = u.pacient_rč
JOIN položky_účtu pu
ON u.id = pu.účet_id
JOIN Lék l
ON pu.lék_id = l.id
JOIN Léčba le
ON pu.léčba_id = le.id
where p.rč = '9511151321'
GROUP BY p.rč;

Tímhle způsobem dostanu celkovou sumu za léky a léčbu (ps: v mysql mám pacienta identifikovaného přes rč)

 
Nahoru Odpovědět 19. května 13:05
Avatar
Odpovídá na Jiří Hrdina
Michal Štěpánek:19. května 16:01

Sumu za jednotlivé výkony (nebo prodej) budeš mít v každém řádku v tabulce "položky_účtu". Celkovou sumu pak budeš mít v tabulce "účet".
Identifikace podle RČ je ten nejméně vhodný způsob, psal jsem ti to už několikrát (a nejen já).Cizince identifikuješ jak, když RČ nemají?
P.S. to "GROUP BY" tam je proč?

Nahoru Odpovědět 19. května 16:01
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:21. května 10:18

pacient: pacient_id, dalsi data - zadne rodne cislo jako id!!!
pokoj: pokoj_id, dalsi data (cislo dveri..., oddeleni_id)
vazebni pokoj_pacient (tve umisteni): pokoj_id, pacient_id, dalsi data (od-do, kdo zaznam vytvoril,... kdo zaznam ukoncil --- treba pri premisteni pacienta, chtel bys dohledat, kdo naridil zmen pokoje)
To mas ok.

A stejnym zpusobem treba ale postupovat pro to ostatni. Logicke celky k sobe.
lek: lek_id, dalsi data (nazev, cena, popis) - to by mel byt katalog leku
Pacient dostane recept. Kdo, kdy vystavil pro koho. Ten propojis pres tabulku s lek_id / recept_id.
Nechapu, na co tam mas tabulky jako cenik, cena. Preci, cena je soucasti katalogu leku. Celkova cena za recept je soucasti receptu. Pripadne, na pokladne by to byl vydejni doklad, opet propojeny na katalog leku.
Jakoze lekar vystavi recept - propojeno na seznam leku.
V lekarne vystavi uctenku, propojene na seznam leku s cenou.
Idealne, kdyby oba seznamy byly stejne. Nebo, kdyz by mely stejna id nebo aspon stejne nazvy polozek. Coz ale presne prakticky nebyva, lekar a lekarna jsou jina firma, vlastni seznamy :) Takhle tezko rici, jak to navrhovat.

Take muzou byt na zbozi ruzne akce. Ruzne kategorie pacientu s ruznymi slevami.

Jo, uvazuj tak, aby tabulkove udaje mohli editovat v excelu. Leky s cenou, Lekare, Pacienty, Oddeleni, Pokoje. Pokud mas cenu u leku mimo tabulku leku, tak se to bude hrozne spatne editovat. Jako, e-shopove.
Pokud ma cenik vice cen pro ruzne skupiny, tak bych tam dal u leku vice sloupcu. Opet, kdyz to budes chtit editovat v excelu, tak tak to mas pohromade. Nebo udelej spesl tabulku se skupinami, kde das treba 5% slevu pro zamestnance na kategorii leky.

Mozna by ses mohl na to vykaslat a rovnou si nainstalovat nektery z free e-shop :) Ten resi tu obchodni cast. A tobe by zbylo resit jen tu cast s recepty. A slo by vyuzit tabulky leku z toho eshopu.

 
Nahoru Odpovědět 21. května 10:18
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:24. května 7:55

zpravy> kolik jaký pacient vydělal nemocnici a jaká mu byla nasazena léčba, kdo ji nasadil a kolik stála. + samozřejmě ta dolní větev.
zpravy> https://ibb.co/mwKEt8

Hele, tak, jestli je to, jak popisujes, pak mas trochu jine tabulky.

  • Lekar propoji pacienta s lecbou.
  • Lecbu je mozne delat nekolika leky najednou a nekolika ruznymi druhy skupin leku.

Cili by mela byt tabulka
id_lecba - moznost 1 - lek 1
id_lecba - moznost 1 - lek 2
id_lecba - moznost 2 - lek 3
Jakoze treba pacienta muzes poslat na chemo, ale taky ne. Nebo mu staci nasadit jenom leky.
Samotna lecba muze neco stat, leky take muzou neco stat. Ted je jeste otazka, kolik lecby leku pacient dostane.

A ono je to tezko rici, zda to ma fungovat presne takhle. Protoze o lecbe rozhoduje lekar, neni to tabulkova hodnota. Lekar vidi, ze mu neco nezabira, tak tu lecbu zrusi, nasadi jinou.
Takze bys mozna mel vest zvlast tabulku, co nasadil lekar a kolik z te lecby pacient dostal. Takze mozna udelat individualne neco jako vydejni doklad z pokladny. Pacienta propojis s chemo, skenem, s nejakym lekem, poctem. Tady zas treba vedet, jakym zpusobem dana lecba fungue, do jakych tabulek sloupcu, co vyplnit. Treba u elmg. rezonance nemocnici nezajima, jak dlouho bezel pocitac, ale jak dlouho bezel skener, protoze ten zere mnohonasobne vice energie. Cili to bude nejaka tabulka cas + zarizeni. Kdezto u leku te zajima treba pocet kusu + lek nebo pocet mililitru + lek.

Hele, a delas to jako komercne nebo je to skolni uloha? Protoze, mozna ti to zbytecne zeslozituji temi uvahami.

 
Nahoru Odpovědět 24. května 7:55
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:24. května 8:11

Mozna, ze tabulka ucet by mela byt jen vysledek sql dotazu.

Mozna bych resil tabulku ucet jako vazebni, takto

pacient_id | lecba_id | lek_id | kusu | ml | datum-cas-od | datum-cas-do | mozna i id_lekar
'pepa' | 'elmg rezonance' | - | - | - | 15.2.2018 6:30 | ...15:30
- | 'penicilin' | 3 | - | 15.2.2018 6:30 | ...15:30 - treba 2 dny dostaval lek, pak uz ne (nektere leky se cas vstrebavaji, takze nektere nelze nasadit hned po jinych, ale musi se pockat)
- | 'adrenalin' | - | 30 | 15.2.2018 6:30 | ...15:30 - tady by se uvedl zacatek mozna i konec operace
 
Nahoru Odpovědět 24. května 8:11
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 41 zpráv z 41.