2010-08-01 14 views
5

Per la maggior parte dei siti principali che è possibile preformare le operazioni CRUD ogni utente ha una propria tabella di database? Mi piacerebbe vedere un esempio di una struttura di database che più utenti, sto guardando la mia struttura di database wordpress e non riesco a immaginare come twitter, tumblr, o anche StackOverflow esegue effettivamente un database. È così facile creare una tabella per un utente in modo dinamico? Grazie in anticipo.Ogni utente ha una propria tabella di database?

+2

Cercherei altre soluzioni prima di risolvere la creazione di tabelle dinamiche. –

risposta

5

Perché ogni utente avere il proprio tavolo? Un utente dovrebbe semplicemente essere una voce in una tabella. Quindi si utilizza l'id di quell'utente per cercare altri record in altre tabelle.

Se voi database contenuto sy 6 tavoli quindi ogni volta che si è aggiunto un youd utente devono anche aggiungere gli altri tavoli ancora troppo.

Così ora avete 10 utenti e 60 tavoli.

+1

Considerate ora di dover connettersi alla tabella corretta per l'utente specifico ... :) –

+0

Yikes! Sì, che incubo – griegs

2

ci sono più diversi tipi di database, ma in genere non. Più comunemente, avresti una singola tabella, ma con un campo che designa l'ID utente. In MySQL, puoi selezionare il sottoinsieme di righe per cui l'ID utente corrisponde a un valore specifico, che è un po 'come creare dinamicamente una tabella per utente.

+0

Le tabelle EAV (Entity-Attribute-Value) sono generalmente detestate: prestazioni scadenti, ma possono essere un male necessario per soddisfare i requisiti di funzionalità. –

+0

@OMG, come entra in gioco l'EAV? Hai tabelle diverse in base al tipo di dati, ma colleghi la voce all'utente tramite un campo. Non sono sicuro di come ciò si riferisca all'EAV. –

1

Non c'è bisogno di una tabella separata per ogni utente. Ma potrebbero esserci alcune ottimizzazioni legate al database.

user rappresenta effettivamente riga della singola tabella. In relazione all'utente ci potrebbero essere altre tabelle per scopi specifici. Supponiamo che la tabella "Commenti" contenga commenti per utente e questa tabella possa avere più commenti da parte dell'utente. Quindi questa tabella utente ha una relazione uno a molti con la tabella dei commenti.

Alcune delle ottimizzazioni che vedo qui sono la creazione di viste (viste materializzate in casi certin), indicizzazione colonna basata sulla domanda di usato, anche partizionamento delle tabelle basate su date/utente o alcuni altri criteri relativi alla applicazione.

+0

Le visioni materializzate sono famigerate come non facili da accettare; il partizionamento delle tabelle è una funzionalità che devi pagare (è disponibile solo nell'edizione Enterprise/Developer di SQL Server, non so su Oracle ...). Entrambi sono concetti oltre a ciò che l'OP sta chiedendo. –

3

La risposta alla tua domanda è "no". Di solito ciò che fanno questi siti è una tabella per gli utenti in cui la chiave della tabella è un campo ID intero e gli attributi sono attributi dell'utente (ad esempio nome, nome della schermata, password, ecc.). In SQLite, appare come segue:

create table User (id integer, email string); 

Quindi si dispone di un paio di tabelle, ad esempio, blog_posts e commenti. Ciascuna di queste tabelle contiene post di blog e commenti di tutti gli utenti. Per identificare un utente, esiste un campo "user_id" che identifica una riga in quella tabella come appartenente a un particolare utente.

create table BlogPosts (id integer, description text, user_id integer); 
create table Comments (id integer, description test, blogpost_id integer, user_id integer); 

La sintassi è simile per altri database. "user_id" lega un post del blog a un utente e un commento a un utente. blogpost_id lega un post del blog a un utente. Ad esempio, è possibile associare ciascun utente a tutte le sue domande e commenti.

È possibile creare una tabella per utente, ma è necessario disporre di una mappatura di quale utente si connette a quale database e occorre aprire sempre nuove connessioni ai database per ciascun utente.

0

Non è possibile eseguire questa operazione in modo sicuro, poiché le query con parametri non possono utilizzare nomi tabella come parametro.

Problemi correlati