11. marts 2004 - 21:41Der er
18 kommentarer og 2 løsninger
Normalisering for eksperter
Jeg er ved at lave en db til en forening indeholdende en kalender.
Jeg regner med at lave en tabel med alle datoer. Derefter skal jeg have en tabel med arrangementer - men de har meget forskellig karrakter - stævne, lejr, ledermøde og andet.
Hvordan skal jeg normalisere dette???
Jeg har læst om 'Vertikal opsplitning af entitet' hvor der oprettes en tabel for hver art arrangement.
Er der nogle gode ideer eller erfaringer med lignende tabelstrukturer.
Hi Niels First I wouldnt have a table with all dates, I would just have a field in your table containing the date. If possible keep all information concerning "arrangementer" in one table, with a relationship to another table containing the "arrangementer" type. As you say yourself. Then when you show the information you can show the relevant fields for that "art"
I cant recall seeing anything about 'Vertikal opsplitning af entitet' so I cant comment on that. If you start splitting your different types into other tables then you will have to take this into account when displaying your data, either by changing sub forms for the specif type or hiding fields etc.
mht. datoer har jeg fundet ud af at det er nemmest at have en tabel med alle datoer i - så kan jeg styre det hele i SQL :o)
tDato : dato tArrangagement: aID(autoNr), arrArt(FK), Dato(FK) tStaevne: aID(FK), ,,,,, oplysn om stævner tMoede: aID(FK), ,,,,,, oplyn om møder tLejr: aID(FK), ,,,,,,, oplysn om lejr og familie turer
Jeg har heller ikke hørt om begrebet 'Vertikal opsplitning af entitet', men jeg kan godt regne ud hvad det drejer sig om. Og jeg vil sige, at det ofte er en afvejning, hvor man må vurdere hvormeget de forskellige arrangementer adskiller sig fra hinanden. Hvis de alle stort set benytter samme kolonner, så er der ingen tvivl om, at de bør ligge i samme tabel. Men problemet er vel netop, at der registreres forskellige oplysninger for de forskellige arrangementer!? Men igen...hvis der kun er én eller 2 kolonner til forskel, så kan man måske godt have 'råd' til at have disse felter tomme for visse arrangementtyper. Men er det flere, så bør man nok splitte det op. Og som Terry skrive, så har man jo broblemer med at skifte recorksoure og felter ud på formularen. Så det optimale vil således være at have en formular til hver arrangementtype.
Men det kunne være intressant at høre om der er en 'facitliste'...!
Der vil nemt komme en H.. mase felter i tabellen tArrangement hvis ikke jeg opretter nogle 'subentiteter' - Jeg har bare ikke rigtig nogen erfaring i det. Og som du siger skal formularer og rapporter laves om hvis klubben kommer i tanker om andre slag arrangementer.
Dalby taler ganske rigtigt om vertikal opsplitning i Databasehåndbogen - men jeg vil nu ikke sige at bogern er anbefalelsesværdig til praktisk databasedesign :-)
Fx har han nogle fine eksempler, hvor han bruger Efternavn som primærnøgle!!
Der sker ikke noget ved at have mange felter i din arrangementstabel, hvis du fylder noget i dem. Er felterne speciefikke for de enkelte typer arrangementer bør du dermod have dem i hver sin tabel med tilhørende formularer og rapporter.
Jeg er enig med terry i det vil være en dårlig idé med en tabel med alle datoerne i. Men det er måske mest fori jeg ikke kan se formålet med den.
Jeg tror jeg vil lade spørgsmålet stå lidt.... og lege lidt med en db - for det kan vel også gå galt hvis der oprettes både et møde og et stævne med samme aID
mht til datoer, har jeg lige scoret en tusse på at 'opgradere' en af mine gamle db'er ved at tilføje 5 år mere til tabellen datoer fordi den udløb her i år 2004 :o) så det har jeg god erfaring med
Jeg kender ikke bogen, men har lidt dårlige erfaringer med Joakim Dalby fra år tilbage (han er dog sikkert blevet bedre siden - det er vi jo alle), men at bruge efternavn som primærnøgle, er ikke umiddelbart det mest kvikke, jeg har hørt om ! ;o)
Men derfor kan bogen jo sagtens være god som helhed.
Det største problem med dalbys bog er nok at den er så hamrende teoretisk. På mig virker det mest som om, at han går ud fra princippet om, at når bare teorien holder, så skidt være med om det kan anvendes i praksis.
Han mangler efter min mening en hel del omkring definition af problemområde, datainsamlig og strukturering mm. altså alt det, der går forud for normalisering, diagrammering mm. Ligeledes har bogen ret store mangler på det, der kommer efter at designet er færdigt, fx brugergrænseflade design, dokumentation mm.
Mht vertikal opsplitning - jeg har da kendskab til det bliver brugt som en rent praktisk foranstaltning for at forbedre performance i et eksisterende system.
Ved at opsplitte tabellen vertikalt kan de forskellige dele (typisk 1 eller 2) placeres på selvstændige tablespaces som igen er på separate raids.
Derudover laver man opsplitningen så kolonnerne splittes op efter hvad der typisk opdateres / læses etc for at minske låse og øge opdateringshastigheden.
Men jeg har altså først set det brugt når systemet har kørt et stykke tid og man har viden om hvad der reelt set sker i databasen, brugsmønstre etc. Tror ikke jeg er stødt på det i designfasen på et system
trer-> Har du en tabel med en række felter og ét af dem kun er udfyldt i meget få tilfælde, kan det med fordel betale sig at splitte tabellen op, så dette felt står i en tabel for sig selv.
Jeg har 12000 ansatte og vil gerne styre hvilket personale nummer, der har hvilken firmabil, så kan jeg vælge at lave et felt til firmabilens registreringsnummer. Men er der kun 8 ansatte, der har firmabil, vil det være mere effektivt at lave en tabel til disse 8.
jkrons> Kan godt se din tanke - men jeg ville nok ikke vælge det (pladsforbruget bekymrer mig generelt ikke og i dit eks vil det kun være omkring 64KB). Det er heller ikke helt hvad jeg forstår ved en vertikal split da man der vil have en 1-1 mapning mellem del-tabellerne - og dermed ingen pladsbesparelse.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
