Mange eller få tabeller, hvad giver bedst performance

2 giver best performance, set ud fra min egen erfaring..

Det kommer nok lidt an på hvilken type queries, du laver mest på dem.

Hvis du næsten altid kun laver opslag på en enkelt bruger (og det er vel det mest normale), så vil det nok være hurtigst at have dem i hver sin tabel.

Men hvis du ofte laver opslag på mange brugere på en gang, så vil det være meget besværligt at arbejde med en tabel pr. bruger, og søgninger vil også være langsommere, for MySQL kan jo ikke (så vidt jeg ved) have et index over flere tabeller.

Hvis der kun er en bruger af gangen på systemet => #2 er hurtigst

Hvis der er flere samtidige brugere på systemet => #1 er hurtigst

(og #1 er langt det pæneste design og vedligeholdelses mæssigt)

takker.. Jeres synspunkter lyder fornuftige.

Sandbox> Svar?

Kommer her. Og lige en ekstra kommentar:

Hvis der er mange skrivninger i forhold til opslag, kan det godt tale til fordel for en tabel pr. bruger, da det nok er hurtigere at skrive ind i et index på en lille tabel end på en stor.

Men da det hele afhænger af så mange detaljer vil jeg anbefale at lave et forsøg, hvor du afprøver performance på en server under realistisk brug med begge metoder.

Du kan også prøve mellemveje - f.eks. 4 tabeller: 1 for hver af a-g, h-n, o-u, v-å. Eller måske en for hvert begyndelsesbogstav. Disse kan det være lidt lettere at skrive queries til krydsopslag på, da tabellerne altid er de samme, så du ikke skal bruge performance på at strikke en query sammen.

Lyder fornuftigt :o)

Og en ide mere, som er lidt relateret til din anden tråd om mange inserts:

Prøv med 2 tabeller: 1 til aktive brugere, og en til ikke-aktive. Det vil sandsynligvis være således at en stor del af aktiviteten på serveren er forårsaget af en mindre del af brugerne (se bare her på E).

Denne løsning vil så indebære at du regelmæssigt kører noget, der flytter brugere mellem de to tabeller.

Formålet skulle være at den tabel, der bliver opdateret oftest dermed vil være en del mindre, og det burde derfor også være hurtigere at lave nyt index til den.

sandbox>

Hvorfor skulle det være hurtigere at skrive til et lille index ?

Uanset om der bruges klassiske index sequential trees eller B trees, så
har jeg svært ved at forestille mig den store forskel.

arne_v:

Det var kun en antagelse, som meget vel kunne have været forkert, men manualen er tilsyneladende enig i min antagelse:

The size of the table slows down the insertion of indexes by log N (B-trees).
http://www.mysql.com/doc/en/Insert_speed.html

Om forskellen er stor nok til at have praktisk betydning overfor de andre faktorer har jeg ingen anelse om. Det er derfor jeg foreslår at afprøve de forskellige muligheder.