Hej du :-)

Jeg er igang med at flytte en større applikation med MEGET MySQL-data. Jeg er lidt i tvivl om det tynger databasen at have mange tabeller fremfor få med med flere rækker. Gør det nogen forskel? Pt. har hver bruger 24 tabeller som fyldes med en masse data. Dem havde jeg egentlig planer om at slå sammen og så indføre en kolonne der hed customer_id eller lignende. Det er dog et kæmpe arbejde og risikoen for at der opstår samkøringsfejl er høj.

Så spørgsmålet er vel egentlig - Gør antallet af tabeller i MySQL nogen forskel for performance?

MySQL er i forvejen ikke den bedste ren performance mæssigt, jeg har hørt om der ude. (Det er dog noget tid siden jeg sidst har rodet med databaser.)

Hvad tager tid, er en query. Så kan du lave to queries (kald til databasen) om til en. Så har du allerede der en meget bedre performance. Og det er hvad det i sidste ende handler om. Og det er netop derfor at man tit opdeler en database i flere tabeller. Da man ikke har brug for at hente alle 24 tabeller hvis man kun vil hente en enkel række i en af dem.

Jeg håber at det gav lidt informationer. Det er det tætteste på noget svar jeg kan give, uden at vide hvad databasen faktisk indeholder. Og hvorfor du overhovedet har hele 24 tabeller.

Jeg er enig med @DHH,. Prøv evt at skrive hvad der er i de forskellig tabeller, så kan vi måske vejlede dig til god måde at gøre det på.

Det kommer også an på hvordan du bruger din database. Det kommer også an på hvor stort data-indhold du skal bruge de forskellig steder ved tabellerne mv.

Der er mange ting som spiller ind over.

Hej @CBOX,

Umiddelbart lyder det ikke særligt effektivt at lave nye tabeller for hver bruger, jeg ville helt klart investere energi i at samle alle brugere og deres data i éen tabel som du også nævner. Det andet kan hurtigt blive noget kludder. Forestil dig du har 10.000 brugere, og du skal tilføje et nyt felt til Bruger-tabellen, så skal du ind og rette 10.000 tabeller versus 1.

Users
ID, Username, Email
1, Morten, morten@sld.tld
2, Peter, peter@sld.tld

Bookmarks
ID, UserID, URL
1, 1, google.dk
2, 1, bing.com
3, 2, v5.dk
4, 1, duckduckgo.com

I eksemplet over her har vi 2 brugere; Morten & Peter. Hver bruger har nogle bogmærker, Morten har bogmærket Google, Bing og DuckDuckGo - og Peter har bogmærket v5.dk.

Jeg håber dette svarede på dit spørgsmål, ellers må du endelig skrive igen, både jeg og de andre meget dygtige brugere herinde er klar til at hjælpe.

Besvar#4 @psto kommenterede for 2 år siden

Tak for jeres svar!

databasen indeholder personfølsomme data omkring kunder, fakturadata, lagerstyring, regnskabsdata m.m.  For at eliminere risikoen for at data blev blandet ved en fejl, eller risikoen for at forkerte data blev præsenteret for en forkert kunde, blev det nuværende setup udviklet således at hver bruger fik et antal tabeller. Antallet heraf er så vokset i takt med at systemet er videreudviklet, og det giver som @daniel også skriver noget administrativt bævl hvor jeg ofte er nødt til at programmere mig ud af at tilføje eller slette en kolonnenfor samtlige brugere. Alle tabeller refererer til hinanden på kryds og tværs og en sammenlægning af data er jeg mange for kan give rod i referencerne. 

Jeg opererer med flere typer af "kunder" ser er mine kunder omtalt som "brugere" samt deres kunder omtalt som "kunder"  

Eksempel (meget forsimplet)

Bruger1_kundekartotek

id, navn

1, Morten

2, Daniel

3, Maria

Bruger1_faktura

id, kunde_id, total

1, 1, 200.00

2, 3, 150.00

3, 1, 500.00

i dag er det jo nemt at at lokalisere Bruger1's data ved at vælge tabellerne startende med "Bruger1" og så forespørge på data herimellem  hvis vi gerne vil se liste over Mortens to fakturaer.

Skal jeg lægge data sammen i én tabel for alle brugere, dog stadig opdelt på kundekartotek og faktura så er jeg lidt nervøs for hvordan jeg får samlet data og får trukket krydsreferencerne på deres kunde_id med Rundt til alle tabeller? Det er jo blot ét eksempel  men derudover kærer en tabel med faktura_linjer som så ikke refererer til kunde_id men til faktura_id.

Det er helt sikkert - hvis jeg for år siden havde den viden jeg har i dag, havde jeg aldrig delt det sådan op i 24 tabeller pr. bruger. 

Jeg aner simpelthen ikke helt hvordan Søren jeg får migrerer data uden at det risikerer at gå galt

Du skal helt sikkert lave det om.

De grunde der er valgt som grundlag for at lave det sådan hænger sammen med manglende viden om det, da der ikke er noget til hindre for at sikre data ikke kan tilgåes af de andre.

Som udgangspunkt kan en god hovedregel være man skal følge de 3 første normalformer - selvfølgelig kan der være undtagelser.

Der er ingen problemer i at hente bruger 1's data selvom de ligger på den anden måde - det handler blot om din SQL forespørgsel som kan laves med JOIN og WHILE for at sikrer det er de korrekte data du får ud :)

Besvar#6 @psto kommenterede for 2 år siden

@Kim; den er jeg helt med på. Systemet er også vokset sig langt større end det var planen oprindeligt. Så du har ret. Det er bygget uden den viden der skulle til, og uden en plan for hvor projektet skulle havde. 

I forhold til "de 3 første normalformer", hvad tænker du der ?

Enig med Daniel

Jeg kan sagtens forstå hvorfor man tænker indblanding, og selvfølgelig logisk set vil det være mere sikkert. Vil anbefale dig at kigge på multi-tenant database design, som jeg ser det er det et skråplan med single-tenant. Da vedligeholdelse af systemet hvis der kommer f.eks 5000 brugere ville kræve enormt meget tid, eller at du har scripts du laver til formålet at f.eks redigere tabeller :-)

Men et lille tip er at du har bestemte rettigheder pr. tenant i dit sytem til databasen, når du nu har et single-tenant databasen, det er en af de gode ting :-)

 #4  Et præcist svar på en migrering af det hele er svær at løse over et forumindlæg, uden nærmere kendskab til data og struktur.

Men i bund og grund tænker jeg det nemmeste er at bygge nogle scripts der læser data ud af de mange tabeller, og samler dem i det nye database-design. Opsæt evt. et dev-miljø hvor du kan lege med en kopi af data, uden det påvirker driften, og så skal koden jo også omskrives lidt til at håndtere det nye database-design, hvilket også vil være en fordel at lege med i et dev-miljø.

Jeg tror det handler om at tage éen ting ad gangen, f.eks. alle brugere først, lave et script der læser dem ud i f.eks. en semikolum-sepereret fil - så du kører alle tabellerne igennem, og for hver tabel laver du en linje f.eks: username;password_hash;email.. 

Efterfølgende kan du på din dev-server lave et script som indlæser dataerne til den nye enkeltstående tabel, der håndtere brugerne, i det nye tabel-design.

Hvis du får brug for hjælp igennem denne process, er du velkommen til at oprette specifikke spørgsmål her i vores forum, så er vi klar til at hjælpe dig, med de problemer du måtte støde på.

Det er naturligvis blot éen måde at gøre det på, der er mange muligheder for at konvertere og arbejde med data, men jeg tænker at dette ville være den nemmeste- og mest overskuelige måde, så er man sikker på at man ikke "piller" ved data i drift-systemet, men blot ekspoterer, for så at lege med dem i et lukket dev-miljø.