[horselover]

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?

[allstars]

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.

[andi]

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

[Filip]

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.

[Daniel.st]

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.

[horselover]

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...?

[tartareandesire]

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.

Originally posted by horselover@Nov 19 2007, 16:33
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...?

[andi]

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.

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

[fors]

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

[horselover]

tack för alla svar!