Hur går man tillväga om man t.ex. vill spara flera personnummer i en tabell ?

Om man t.ex tar en Bokningstabell som ska innehålla....

Bokad läkares personnummer
Bokad Patients personnummer
Dtum
Tid
m.m.

Kan man koppa en sådan tabell till en Personregistertabell som håller alla personer ?
Eller måste man ha ett "läkarregister" och ett patientrgister?
Det kan ju bli så att även än läkare måste gå till "doktorn".

Några bra ideé på detta?
/Ricky

Jag skulle dela upp det så här

Person
---------------------
id
personnummer
namn
typid
m.m.

PersonTyp
---------------------
id
typ (läkare, patient, m.m.)

Bokningar
---------------------
läkare (personid)
patient (personid)
datum
tid


Eftersom man har "typtabellen" så vet man om "personen" är läkare eller patient.

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Frågan är vad man gör om en läkare blir behandlad. :oP

Men det kanske inte är nödvändigt med en "många till många" relation.

Tycker det är en bra datastruktur. Men vill helst använda en annan namn standard

Tabell: tblPersons
---------------------
Fält: PersonId int (autoinc.)
Fält: PersonNo int
Fält: PersonNamn varchar(50)
m.m.

Tabell: tblRoles
---------------------
Fält: RoleId int (autoinc.)
Fält: RoleName varchar(20)
m.m.

Tabell: tblReservations
---------------------
Fält: ReservationId int (autoinc.)
Fält: ReservationDate datetime
m.m.

Tabell: tblReservationPersons
---------------------
Fält: ReservationPersonId int (autoinc.)
Fält: ReservationPersonRole int - > tblRoles.RoleId
Fält: ReservationPersonReservation int - > tblReservations.ReservationId
Fält: ReservationPersonPerson int - > tblPersons.PersonId


Detta är en mer dynamisk läsning. Då en bokning kan ha en eller flera läkare. Möjlighet att t.ex. lägga till roller som: Specialist, Läkarstudent, osv.

Ger oxå möjlighet för en läkare att behandla sig själv. He, He. Vill se en hjärnkirurg göra det. ;o)

Patriks lösning stödjer ju också att läkare blir behandlade (och behandlar sig själva) iom att bokningstabellen refererar till personid:t och struntar i vilken typ läkaren respektive patienten är.
Den enda fördelen med den senare modellen är som jag ser det att flera läkare kan hålla i en bokning. Om denna finess ej behövs bör man nog köra på den enklare varianten.

Bara en allmän undran, varför döpa tabeller till tblXXXX?
Jag har alltid undrat vem som hittat på det ofoget...

Först kan jag ju nämna att mitt förslag var ett teoretiskt förslag inte en "namngiven" lösning. ;)

Att döpa tabeller med tblXxx är något som många gör för att man ska veta att det är en tabell. Jag gjorde det själv när jag började med utveckling, döpte även mina lagrade procedurer till sp_xxxxx.
Varför? Vet faktiskt inte varför jag gjorde det. Efter ett tag så upptäcker man själv att det inte precis har någon funktion. Man vet mycket väl att det är en tabell utan att det står tbl i namnet.
Vad som är viktigare är att veta vad tabellen och sp:n innehåller.
Personligen föredrar jag att ha ett prefix på tabell och sp som visar vilken applikation de tillhör. T.ex. de tabeller och sp som hör till min distributionshantering heter Distribution_Xxxxx.

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Jag har det för att kunna skilja på vyer och tabeller. Vilket annars är svårt i SQL fråga. Då det kan vara både fråger och tabeller. Men det räcker ju i och för sig att bara särskilja vyer. Men är inte lika konsekvent som att ge bägge ett prefix.

>
>Patriks lösning stödjer ju också att läkare blir behandlade (och behandlar sig själva) iom att bokningstabellen refererar till personid:t och struntar i vilken typ läkaren respektive patienten är.
>Den enda fördelen med den senare modellen är som jag ser det att flera läkare kan hålla i en bokning. Om denna finess ej behövs bör man nog köra på den enklare varianten.
>

Jag ber om ursäkt att jag framförd det som att det var en skillnad eller fördel.

Fördelen med den dynamiska lösningen är att rollerna inte är fasta. I den andra strukturen måste du för ändra datastrukturen för varje roll du vill lägga till en bokning. T. Ex. Sjuksyster, skötare kräver ytterligare kolumner. Medans min datastruktur inte kräver någon förändring.

Det är ju inte alltid en bokning kräver läkare. T. Ex. kan man ju besöka distritskssköterskan.

Skillnaden är alltså: om en person tilldelas "Fast" vs "Dynamisk" roller för en bokning.

Mitt sätt att få er andra att göra dynamiska lösningar. Ger användaren mer möjligheter att använda systemet. Slipper ge er merarbete för att en kund "glömde" berätta att en bokning inte behövde ha läkare utan enbar sjuksköterska.

Jag håller med Andreas här. Min lösning ovan var lite hastigt ihopsatt.
Precis som Andreas så använder jag rollbaserade applikationer. I mitt fall rör det sig ofta om t.ex. Adminstratör, Redaktör, Användare, Prenumerant, Projektledare, m.m.
Ett dynamiskt rollbaserat system är suveränt att ha med redan från grunden i en applikation. Det gör det lättare att återanvända lösningar.

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

> Jag gjorde det själv när jag började med utveckling, döpte även mina lagrade procedurer till sp_xxxxx.

Har inte med tråden att göra, men detta är inget att rekommendera, heter Stored Proceduren sp_xxx så innebär detta en prestandaförsämring... (om Stored Proceduren inte ligger i Master)..

Inte fel att använda prefix för lagrade procedurer. Men som budda säger. ANVÄND INTE: "sp_......" t. ex. sp_AddCustomer

Själv gillar jag inte "underline" (_-tecknet) så jag döper dem till "sp......" t. ex. "spAddCustomer"

Detta borde ju inte ge prestandaförlusten som sp_ gör men pånnai tillräckligt mycket om sp_ för att man direkt skall veta att det rör sig om en lagrade procedurer.

> Inte fel att använda prefix för lagrade procedurer. Men som budda säger. ANVÄND INTE: "sp_......" t. ex. sp_AddCustomer
>
>Själv gillar jag inte "underline" (_-tecknet) så jag döper dem till "sp......" t. ex. "spAddCustomer"
>
>Detta borde ju inte ge prestandaförlusten som sp_ gör men pånnai tillräckligt mycket om sp_ för att man direkt skall veta att det rör sig om en lagrade procedurer.


Om någon undrar varför... Klippt från nätet:

<info>
SQL Server gives name-resolution preference to the master database for procedures that have the sp_ prefix. SQL Server looks for a compiled plan for the procedure associated with the master database and doesn't find it. SQL Server assumes the procedure isn't in cache (and thus must be recompiled) and acquires an exclusive compile lock on the stored procedure for a short time. However, the short time that the lock exists is enough to cause performance problems.
</info>

Hej !!

Om jag har förstått det rätt så är Andreas lösning den man ska bygga efter.

Kan man då med hjälp av denna lösning få fram t.ex.

En läkares alla bokningar med patientnamn, datum, tid mm.
Eller se en patients bokningar med läkarnamn, datum, tid mm.

Om jag har förstått det rätt så håller "tblReservationPersons" alla bokningar, borde då inte denna tabell innehålla både patientens Id eller No OCH läkarens Id eller No för att kunna få fram uppgifter enligt ovan...

Stödjer denna lösning att läkaren "Pelle" som enligt tblRoles är läkare även kan vara patient till en annan läkare, för "Pelle" blir ju också sjuk ibland.

/Ricky

Det är tblReservations som innehåller alla bokningar och information om dessa.
Sedan innehåller tblReservationPersons informationen om vilka personer som är inblandade. Det kan t.ex. vara patient, läkare, narkosläkare, sköterska, undersköterska, osv. Eftersom tabellen tblRoles finns och varje person i tblReservationPersons får en roll så kan man på detta sätt lägga till x antal personer i en bokning.
För att få fram en läkares bokningar gör man då en sökning i tblReservations och tblReservationPersons där läkarens id finns tillsammans med rollen som läkare. Motsvarande sökning görs för patienter, sköterskor osv.

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Jag kanske är för trött eller nåt, men... jag förstår inte fördelen med den senare lösningen framför Patriks första lösning.

OK, vissa små modifikationer kanske behövs: Fältet "läkare" i tabellen "bokningar" kanske borde heta "vårdare" eller något annan mer generellt. Patient är inte heller en lämplig roll eftersom även en läkare kan vara patient. Vem som är patient framgår istället av reservationstabellen.

Det Andreas lösning tillför är väl att den tillåter att fler än två personer är involverade i en och samma bokning, så att t.ex. en läkare, två undersköterskor och en patient finns med i samma bokning. Om detta behövs är det en bra lösning. I annat fall tycker jag att den blir onödigt komplex.

Jag har skrivit om och (förhoppningsvis) förtydligat den första lösningen här. Jag har använt Andreas syntax och lagt till PK för att indikera primärnyckel.


Tabell: tblPersons
---------------------
Fält: PersonId int (autoinc.) PK
Fält: PersonNo int
Fält: PersonNamn varchar(50)
Fält: RoleId int - > tblRoles.RoleId
m.m.

Tabell: tblRoles
---------------------
Fält: RoleId int (autoinc.) PK
Fält: RoleName varchar(20)
m.m.

Tabell: tblReservations
---------------------
Fält: ReservationId int (autoinc.) PK
Fält: ReservationDate datetime
Fält: ReservationPerson int - > tblPersons.PersonId
Fält: Patient int - > tblPersons.PersonId



Jag tror att detta är ett enklare sätt att lösa problemen.

Min första lösning som du fixat med är en enklare lösning men har den stora nackdelen att den inte är skalbar. Den tillåter bara en läkare och en patient för en bokning.
Andreas lösning är bättre för att den är mer anpassningsbar och är den jag själv skulle välja, trots mitt första förslag. Anledningen är att om du bygger "min" lösning och sedan kommer på att du faktiskt behöver fler personer i en bokning så får du ett dj***a problem att uppdatera lösningen så att den funkar. I detta fall är det bättre att gå med den "större" lösningen.
YAGNI, som ofta används, kan betyda You Aren't Gonna Need IT eller You ARE Gonna Need It. ;)

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Det är inte bra databas förändringa vi talar om utan. Vid förändring blir du tvungen att även förändra applikationen för att den skall följa den nya databasstrukturen. Fördel om du är datakonsult. Extrapengar at tjäna. ;o)

Med dynamiska lösning så behöver du bara göra applikationen en gång. Ssedan funkar den oavsett hur du förändrar data i databasen. Det är denna fördel Patrik Dahlén försöker tala om för dig.

Lösningen kanske kan vara lite krångligare att implementera. Men den ger dig så mycket mer tillbakas.

Se det som en ikea möbel. Du får kanske göra mer jobb själv. Men den blir en så "mycket"(gillar inte svordomar så jag väljer att använda det mindre kraftiga ordet "mycket") bättre och "snyggare" lösning.

Hellre en "för bra" lösninge än en "för dålig". Jag tror användara av datastystem håller med mig. Man kansk inte märker när ett system är "för bra". Men du kommer garanterat märka när det är "för dålig".

Osv...

För att få ett slut på denna tråden. ;o)
Gör ett "bra" val: den dynamiska lösningen...

Ja, om det finns någon chans att det blir fler personer involverade i bokningen, är den dynamiska lösningen bättre. Jag förstår fördelarna med den. Ibland tenderar jag dock att ramla in i extreme programming-banor, dvs gör enklast & snabbast möjliga från början och skriv om vid behov.

Ett tillägg (eller förtydligande - detta kanske var underförstått) till lösningen skulle kunna vara att ha RoleId även i tblPersons, för att skilja ut de som innehar kompetens att vara t.ex. läkare. Eller rent av ha en kopplingstabell mellan tblPersons och tblRoles ifall personer ska kunna inneha flera roller/kompetenser.

Hoppas nu att Rickard fått svar på sin fråga och förstått den dynamiska lösningen!

Jag har nog inte förstått allt, men om ni säger att detta är den lösning som man bör använda så kör jag efter det.

1) Om jag har förstått det rätt så kan man inte se om en person är läkare, innan han har blivit bokad
som läkare på en bokning.

2) Tycker även att det är svårt att få fram alla uppgifter om en bokning.
tblReservations innehåller alla uppgifter om en bokning, men när man vill få fram vilka två personer
som tillhör bokningen så får man ju fram två rader från tblReservationPersons.
All denna information skulle jag ha velat få fram som en rad, typ...
Datum, Tid, PersonNrLäkare, NamnLäkare, PersonNrPatient, NamnPatient....och inte som nu

Datum, Tid, PersonNrLäkare, NamnLäkare
Datum, Tid, PersonNrPatient, NamnPatient...för att sen på något sätt koppla ihop dessa två.

Hade tänkt att jobba med denna information i ett Dataset i C#, och då hade det nog varit lättare om
all informatin fanns på "samma rad".

Jag får försöka att lösa det på något sätt.

Tack för hjälpen
/Rickard

<b>Jag har det för att kunna skilja på vyer och tabeller.</b>

Varför skilja på dem?

Antag att du i dagsläget har en del data i en tabell, men senare stukturerar om databasen så att samma data hämtas via en vy. Utan prefixen hade du kunnat ge vyn samma namn som tabellen hade och därmed slippa ändra alla frågor. Med prefixen måste du ändra namnet i alla frågor.


Från "Linux kernel coding style" angående "ungersk notation" (dvs att koda in typer i namn):
<b>Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.</b>

Låt oss säga att du kör

SELECT * FROM Orders

Du får 300 000 rader tillbaks och det tar 4 sek. Sedan kör du

SELECT * FROM OrderList

Du får 300 000 rader tillbaks och det tar 12 minuter! Varför?
Jo det visade sig att OrderList var en fet vy.

Det KAN vara bra att göra skillnad på dem.

/micke

<b>
>
>Varför skilja på dem?
>
</b>
Jag ser inget som hindrar från att undanta sig namn standarden då det rör sig om vyer för bakåtkompabilitet. Då man förändrar datastruktur i en databas men vill behålla kompabiliteten är vyer ett mycket bra hjälpmedel. Då man kan ge tabellen ett nytt namn och skapa en vy som ser ut som den gamla tabellen.


<b>
>
>Från "Linux kernel coding style" angående "ungersk notation" (dvs att koda in typer i namn):
>
</b>

Jag har för mig att "ungersk notation" i huvudsak avser variabelnamngivning.

Jag kan hålla med om att det är ofta onödig. Den för med sig fler nackdelar än fördelar.

Viktigare är att använda riktiga fält-/variabelnamn. t.ex. KundId, KundPersonNr, KundNamn, KundAdress, KundPostNr, KundOrt istället för lngKID, lngKPERSN, strKNAMN, strKADRESS, lngKPOSTN, strKORT.

Då man använder naturliga namn är det lätt att dra slutsatser vilken datatyp fältet är. Givetvis kan man lagra tal som text. Dett är lämpligt vad det gäller telefonnummer. Då det ofta underlättar att inkludera skiljetecken i ett telefonnummer t. ex. "+46(0)31-80 08 70" jämfört mot 4631800870.