Klurig outer join

Hej!

Nu sitter jag med en klurig SP som jag inte riktigt lyckas få till. Det handlar om ett närvarosystem uppbyggt av två tabeller. en frånvarotabell samt en närvarotabell. en användare är antingen frånvarande genom att ligga i frånvarotabellen där det även finns en flagga som besrkiver typ av frånvaro, eller så är användaren närvarande på ett av två sätt. antingen ligger han i närvaro listan där det finns att kommentar fält precis som i frånvarotabellen eller så ligger han inte i någon av de två listorna. Alla deltagar finns listade i en separat tabell och alla tillfällen finns listade i en separat tabell. Användarinfo som även den skall fås ut ligger självklart oxå den i en separat tabell.

Att lista frånvarande personer är inget problem utan problemet ligger i att lista närvarande deltagare och få ut kommentar fältet som skall vara NULL om användaren inte ligger i någon tabell. Min Left outer join ville inte riktigt fungera, säkerligen främst på mitt nuvarande join handikapp.

Två olika SP's skall finnas, en som ger närvaro och frånvaro separat för alla deltagare vid ett specifikt tillfälle samt en som listar alla närvaro- och frånvarotillfällen för en specifik deltagare för alla tillfällen.

Närvaro respektive frånvaro hade jag tänkt få ut som en tinyint flagga.

Några förslag på hur dessa SP's skulel kunna se ut i MS SQL 2005?

Om närvaron inte lagras i närvarotabellen, hur vet man då att användaren varit närvarande vid det specifika tillfället?

Testa 3 stycken union.

emission skrev:

Om närvaron inte lagras i närvarotabellen, hur vet man då att användaren varit närvarande vid det specifika tillfället?

Alla deltagare finns listade i en deltagarlista som nämnt och varje tillfälle har en flagga som säger om närvaron är aktiverad eller ej. Sen vid aktivering så anger man närvarande personer och resten hamnar i frånvarotabellen.
Så om närvaron är aktiverad på tillfället så vet man att alla icke närvarande lagts i frånvarotabellen och kan således utgå från att alla som inte ligger där är närvarande.

En ytterligare optimering som ligger är att närvaron sammanställs för varje deltagare i deltagartabellen för att slippa den krångliga queryn som jag frågar om när den inte behövs. Komplext, jo kanske men man får hålla tungan rätt i mun och utgå ifrån att man täcker upp alla fall tills man blir bevisad motsatsen.

mo:d:fi skrev:

En ytterligare optimering som ligger är att närvaron sammanställs för varje deltagare i deltagartabellen för att slippa den krångliga queryn som jag frågar om när den inte behövs. Komplext, jo kanske men man får hålla tungan rätt i mun och utgå ifrån att man täcker upp alla fall tills man blir bevisad motsatsen.

Det finns ingen som helst anledning att lagra närvaroinformationen någon annan stans än i deltagarlistan, och jag skulle till och med vilja säga att det är fel att göra det på något annat sätt.

Lägg till närvaro- eller frånvaroflagga, kommentarfältet och frånvarotypsflaggan (som kan dubbelarbeta som närvaro- eller frånvaroflagga) i deltagarlistan, och hela problemet är löst.

Deltagarlistan fungerar så att man har en post per "kurs" och användare eller vad man abstrakt skall kalla det. Det finns sedan flera närvarotillfällen per "kurs" vilket gör att din lösning inte håller. Jag hade även tänkt att systemet skulle skalas för att klara ~100k användare med vardera 4-5 närvarotillfällen per dag. Närvarotillfällena sparas sedan i tabellen i 6 månader vilket ger ~6*20 * 5 * 100k = ~6miljoner poster. Visst har jag förtroende för sql men inte tillräckligt för att tro att den klarar så många poster med bra prestanda över för resten av systemet.
Tanken vid lagring av bara fånvaro är att man kan skala antalet poster med 70-90% vilket ger dramatiska förbättringar.

Ok, då förstår jag upplägget, och återkommer med förslag till lösning. Dock kan jag generellt säga att det inte är stora databaser/tabeller som ska undvikas, utan komplexa och snåriga strukturer, där man "får hålla tungan rätt i mun". Det är enklare att få bra prestanda med 100 miljoner poster i en bra och enkel struktur än med 10000 poster i en snårig.

Jag följer ditt råd och kör allting i samma tabell. I värsta fall så är prestandan inte det bästa och man får försöka skriva om det senare men du har nog rätt i att en stor tabell är bättre än en snårig struktur.
Tack för förslagen.