Om man bygger ett fleranvändarsystem(första gången) där varje användare kan spara undan information, typ dagligen...

Ska man då skapa en ny tabell för varje användare (vid registreringen) där användaren lagrar sin info.

Eller ska man skapa en tabell med användare och en ENORM tabell med alla användares information.

I första fallet kan det bli himla många tabeller men känns snabbare än andra fallet då en ganska långrandig matchning som måste göras.

Undrar vad som är standard att göra?

det beror mycket på hur många användare du talar om och hur mycket data de förväntas att spara/lagra.

Större communitys använder både flera tabeller och databasen för användardata.

Jag tycker inte du skall ha en tabell per användare, däremot inte sagt att du bara skall ha en info-tabell. Hur mycket information är det som skall sparas? Går det kanske att dela upp det som användarna skall spara i olika kategorier för att göra tabellerna logiska och översiktliga? Om alla användare skall spara samma saker kan det ju vara som kolumner i en tabell, men om en användare kan spara 1, 5 eller 100 bilder får du ju ha en speciell bildtabell med en relation till en användartabell osv.
Beskriv mer i detalj vad systemet går ut på så är det lättare att avgöra!

/Andreas

Du ska definitivt ha en tabell med alla användare i, det räknas som standard.
Jag har väldigt svårt att se något tillfälle då man skulle vilja att varje användare har en egen tabell.

Det underlättar att hjälpa till om du beskriver vilken typ av information du vill lagra.

Inte en tabell för varje användare.

Jobba med index och liknande för bättre prestanda i en större tabell.

En variant kan vara att ha en tabell med alla rader och en annan tabell med de rader som läses oftast, ex. alla rader från den senaste veckan eller liknande. Det finns absolut tillfällen då det kan vara bra att bortse från kraven på en fullständigt normaliserad databas just för få upp prestandan.

Tack gott folk :-).

Säg att det är en kalender, så kan användaren lagra info i några fält på varje datum under ett år. Då skulle ju username+datum bli nyckel.

Då får man koda så att det aldrig blir insert på datum som redan finns, då ska det vara update, så att varje user har 365 unika datum.

typ...?

Förstår inte riktigt vad det här har med ursprungsfrågan att göra men skulle liksom de flesta andra här råda dig till en enda tabell för användare men dock inte nödvändigtvis en tabell för informationen som är kopplad till användaren. Den skiljer sig så oerhört mycket från fall till fall att det är omöjligt att svara på generellt.

I ditt exempel så kan man ju lägga upp det hela på olika sätt. Ska det kunna vara flera inlägg på en dag kör du ju sällan några updates (om man nu inte ändrar tidigare inlägg) utan inserts hela vägen.

Du gör helt rätt i att du tänker efter innan du börjar programmera så du slipper göra en massa jobb i onödan om du ser dig tvungen att göra ändringar i databasdesignen.

Du behöver ju inte skapa dessa fält innan någonting är sparat utan du kan ju ha en tabell där alla "kalendernoteringar" ligger. Ett fält är user_id, ett är datumet och så ett fält för texten eller vad det nu är. Då behöver du ju inte ha en massa tomma fält från början. Det går ju att skriva en SQL-sats så att den gör INSERT i första hand och UPDATE om nyckeln redan existerar (user_id + datum).

/Andreas

Gör en snygg databaslayout med bra uppsatta index och optimera den sedan när du måste.

tack för alla svar!

Din frågeställning gör att det känns som att du borde läsa på lite om relationsdatabaser innan du börjar. Jag misstänker att du tänker väldigt fel, och om du inte lär dig att tänka rätt först kan det bli väldigt jobbigt.

Optimera innan du måste om du misstänker att du kommer ha behov av det =) Kan spara mycket tid. Räknar man med minst några tusen besökare om dagen och har många databasanrop på varje sida kan det eventuellt vara en idé att spara genererad html i databasen.

Det håller jag inte med om. :) Några tusen besökare per dag är ju inte så jättemånga heller, för den delen. Jag tycker att det är bättre att hålla databasen så ren som möjligt. Däremot kan man cachelagra saker i minnet med Memcache eller liknande, vilket egentligen ger samma resultat.

Saken är ju den att programkoden blir mer och mer komplex desto fler optimeringar man gör. Samtidigt så händer det ibland att man optimerar fel saker när man optimerar när tidigt. Jag säger inte att optimering är dåligt, utan bara att det är dåligt om man gör det för tidigt.