Strukturering af database

Det generelle princip, som jeg har forstaaet det, er at du strukturer databasen efter strukturen i de data du skal opbevare, data i 3 Normal Form (eller hoejre.)  Typisk har man for brugere en tabel med en raekke for hver bruger identificeret med bruger id og saa kolonner for alle data der afhaenger direkte af den enkelte brugerid, altsaa navn, foedselsdag, cpr nummer o.s.v.  Jeg har aldrig hoert om fordele ved at splitte en saadan tabel op i en tabel for hver brugerid.  Det er ogsaa min forstaaelse at MSSQL og andre moderne database systemer let kan behandle tabeller med millioner af raekker.

Naturligvis, hvis du saa har data hvor der kan vaere flere vaerdier for en enkelt bruger, saasom telefonnummer, saa laver du en saerskilt tabel for telefonnumre hvor en af kolonnerne refererer til brugerid, og hvor du har data med saakaldt mange-til-mange relationer, saasom foreninger hvor en bruger kan vaere medlem af mange foreninger og hver forening kan have mange medlemmer, saa laver du en tabel for foreninger med, mindst, kolonnerne foreningid og foreningnavn og en tabel bruger_forening med (mindst) kolonnerne id, brugerid, og foreinigid.  Alt i overensstemmelse med principperne for normalisering.

Jeg kan komme med et konkret eksempel:

Jeg har pt følgende tabel, som basis tabel for brugerne:
users
- id
- username
- password
- fullname
osv osv

Så er der 2 måder at strukturere bogholderiet på:

1 tabel med 8-10 kolonner hvor den ene henviser til brugerid'et i "users"-tabellen. Og alle brugeres bogholderi-data ryger så derind.
Denne tabel vil om året få tilført i omegnen af 100.000 rækker, som dog kan få en arkiveringsmulighed i en arkiv tabel, så den aktive tabel altid vil have så få som muligt lagret, men vi snakker stadig i denne størrelsesorden af nye rækker årligt.

Den anden måde kunne være over 200 tabeller med et id i navnet, fx bookkeeping_12 hvor 12 er id'et på brugeren i "users"-tabellen. Denne har også 8-10 kolonner, men vil så årligt få tilført små 500 rækker, fremfor 100.000.
Tilgengæld er der så tale om en lagring af flere hundreder tabeller over en længere periode med få rækker.


Så vidt jeg lan læse, foreslår du så løsning 1 med 1 tabel?

Konsekvensen af dit forslag 2 ville være, at du intet kan automatisere uden en kæmpe indsats. Databaser er bygget op på princippet, at man kan operere på data i tabeller vha kriterier. I dit forslag 2, ville man tillige skulle finde ud af, eller specificere, hvilken tabel man skal lede i, afhængigt af hvilke søgekriterium man anvender på samme type af data. Det er fuldstændigt uhåndterligt. Så ja, din løsning 1 er det eneste holdbare.

Løsning 2 kan sagtens automatiseres vha ASP-variabler.

Men jeg styrer databasen manuelt engang imellem, dvs. ved oprettelsen af diverse tabeller i opstartsfase, etc, vha. SQL Manager Lite-programmet, og hvis der så er flere hundrede tabeller, vil DET ihvert fald være overskueligt :)

Det jeg var mest bange for ved løsning 1, var at selvom kriterier var påført i SQL-udtrækskoden, ville databasen stadig køre langsomt grundet de utrolig mange rækker, men det lyder som om, at dette virkelig ikke er noget problem? :)

For endnu en gang: nej det er ikke noget problem. Hvordan forestiller du dig Google, Facebook, YouTube, Wikipedia, CPR registret osv  kører?

Du skal bare sætte index på de relevante felter.

Og i parantes bemærket: alt kan lade sig gøre, men ikke alt er lige fornuftigt. At rode rundt med tabelnavne som variable ville i dette tilfælde være et redunant kodemæssigt mareridt.

Jeg var vaek.  Nu sidder jeg og naerlaeser dit #3.  Jeg tror du fortaeller at du har cirka 200 brugere og at du for hver bruger foretager gennemsnitligt 500 bogfoeringer om aaret.  Du har saaledes to slags 'ting,' brugere og bogfoeringer.  For brugerne har du en tabel `users` med en raekke for hver bruger identificeret med et userid og med felter for username, password, o.s.v.  Der er cirka 200 brugere i tabellen.  Saa skal du have en tabel, eller maaske mange tabeller, for bogfoering med, mindst, et felt for brugeren og en halv snes andre felter sandsynligvis for dato, beloeb, transaktionstype, o.s.v. 

Er det korrekt opfattet?

I saa fald er der for mig ingen tvivl om at du skal have en enkelt tabel `bogfoering` der indeholder alle bogfoeringer for alle brugere.  Det er precist den struktur alle moderne Relational Database Management Systems (RDBMS) er lavet for.  Jeg har hoert, men ikke set beviser for, at en tabel med en million raekker ikke skulle vaere noget problem.  Og hvis du skulle rende ind i problemer maa loesningen vaere at skifte til et stoerre RDBMS system, ikke at manipulere med tabelstrukturen.

Hvilket neoman ogsaa synes at sige.

Jeg vil i oevrigt gaette paa at du har andre tabeller, for eksempel en tabel for transaktionstype hvor du maaske har id og navn for 50 forskellige ting der kan bogfoeres for saaledes at din bogfoeringstabel kun behoever en id for transactionstype, o.s.v.

Du skal helt klart kun have en bogholderi tabel med en kolonne som peger paa bruger.

Saet index paa feltet, saa er der ikke nogen problemer med soege hastighed.

100000 raekker af lad os sige 200 bytes per raekke er 20 MB.

Det er ingenting.

Ja hvis du koerer paa en 486 med en 40 MB harddisk fra midt i 90'erne er det meget.

Men paa en nyere maskine er det ingenting. Paa en 2 TB disk vil der vaere plads til 100000 aars data.

I har mig overbevist om den rigtige måde er løsningen med 1 tabel :)

Super fedt, at få tingene bekræftet, og kan se at jeg skal en anden ting om, hvor jeg har benyttet mig af metoden med flere tabeller.

Tricket med at sætte index på feltet, var jeg faktisk ikke klar over, så det vil jeg da benytte mig af i fremtiden, på det felt som henviser til ejeren af rækken, dvs. brugeren i brugertabellen.

Jeg siger mange tak for hjælpen, men er nu i vildrede om hvem dælen der skal have pointsne ?:)
Derfor, alle som mener de bør have andel heri, skal smide et svar, og jeg vil acceptere dem i morgen aften :)

Tak for hjælpen gutter!

erizias, du kom ikke tilbage og lukkede spoergsmaalet.  Du fik kun et svar, #7 fra mig.  Hvis du foretraekker alligevel kun at give en del af de 60 points til mig har du den mulighed for selv at oprette et svar og give dig selv resten af pointene.  Men under alle omstaendigheder, nu hvor det stillede problem er loest maa du soerge for at lukke spoergsmaalet.

Beklager, at jeg ikke nåede tilbage i starten af ugen, men grundet personlige årsager, har jeg slet ikke været i nærheden af en computer siden.

Spørgsmålet er nu lukket og points uddelt.