[Helix]

Funderar lite vilket egentligen är bättre för prestandan. Skall ha en applikation där varje användare kan antingen få två tabeller i databasen eller så använder man två tabeller för att lagra all information för alla användare.

I vilket fall blir prestandan bättre i längden?

1. Det blir många tabeller i database och ökar med antalet användare.
2. Det finns få tabeller i databasen (ökar ej), som istället ökar i storlek tills tora mängder.

Någon som vet eller sett några tester som körts? Vilket är det mest optimala?

[tydal]

Om du funderar på fall 1 så låter det som att du inte ska använda en SQL-databas utan jobba direkt mot filsystemet.

Fall 2 är hur man normalt använder SQL-databaser.

I fall 1 har du ingen samordning. Du vet inte hur många användare du har. Du vet inte vilka användare som uppfyller vissa villkor. Du vet ingenting om några användare tillsammans, utan du vet bara något om var och en för sig, som en isolerad företeelse. Det är kanske så du vill ha det, men i så fall får du bäst prestanda utan en SQL-databas.

[mbomelin]

Det beror ju även på designen av tabellen tycker jag. Det blir kanske ohållbart i längden om du har en fet tabell med låt säga fulltext-index på 15 kolumner.
Det funkar upp till ett visst antal användare men är ganska ohållbart för ett par miljoner användare då indexen kommer bli så stora så de inte går att hålla i minnet, och att jobba med tempfiler på disk är dyyrt.
Det hela är egentligen en ekvation mellan
[edit]
(Katten kom åt enter-knappen)

...mellan antal användare, tabelldesign, indexdesign och vad du har för hårdvara.

Att ha en tabelluppsättning per användare är dock inget jag nånsin sett. Gör isåfall hellre en gemensam uppsättning per 1000 användare, genom att ha koll på vilka användare som finns var så kan du göra en query till rätt tabell, och vid sökningar i alla tabeller kan du använda en MERGE-tabell.

[yoggi2k5]

Funderade själv över detta för inte så länge sen. Hittade då detta när jag sökte efter svar:

http://bobfield.blogspot.com/2006/03...on-tables.html
http://forums.mysql.com/read.php?125...7451#msg-87451
http://forums.mysql.com/read.php?125...4239#msg-84239
http://forums.mysql.com/read.php?125...788#msg-111788

Allt pekade åt att jag skulle köra med en uppsättning tabeller, så jag gjorde ett litet test där jag körde lite SQL-frågor mot en databas med 1 miljon, 10 miljoner och 50 miljoner rader. Visade sig att med lite tweaks så fungerade det riktigt bra.
Mitt tips är att du sätter upp en uppsättning tabeller och kör ett par test frågor efter att du fyllt den med massa junk-data. Tar inte speciellt lång tid att genomföra och du får svar på om det fungerar eller inte.

[fors]

Rent teoretiskt, tidskomplexiteten är O(log) vid sökning i en databas som är indexerad. Detta medför att det krävs 20 jämförelser för att söka upp ett värde när det är 1 miljon rader. När det är 25 miljoner rader så krävs det 25 jämförelser. Och för 1 miljard rader så krävs det 30 jämförelser. Som du ser så ökar inte antalet jämförelser särskilt mycket när datan växer. Detta är rent teoretiskt och det borde se ut någorlunda lika i verkligheten.

Ett problem som finns om indexdatan ligger på disk, då blir det höga söktider. Så det vore optimalt om indexfilen fick plats i minnet. Jag har en tabell på en site där antalet rader är 1,5 miljoner. Jag indexerar två stycken int-kolumner och storleken uppgår till knappt 28 kB.

Min poäng är alltså att om man har indexet i minnet och indexerar korrekt så gör det inte så mycket om det är en stor tabell. Jag är inte jätteinsatt i MySQL eller databaser i allmänhet rent praktiskt rörande prestanda på det här viset, så rätta gärna mig om jag har fel. Men tidskomplexiteten är i alla fall sådan rent teoretiskt. Det finns alltså en anledning till varför många faktiskt väljer att ha en tabell och inte flera tusen.