Qual è il miglior progettazione di database per mille righe

Question

sto per iniziare una Database Design che semplicemente gestire gli utenti in aziende.

• Ogni azienda avrà un'area di amministrazione in grado di gestire gli utenti
• Ogni azienda avrà circa 25.000 utenti
• Client crede di avere circa 50 aziende per iniziare

La mia domanda principale è

Devo creare le tabelle sulla base di aziende? come

users_company_0001 users_company_0002 users_company_0003 ...

come ogni azienda userà mai gli utenti "altro" e non avranno bisogno di somma / contare diverse tabelle in tutta user_company (una semplice JOIN farà il trucco, anche se è più costoso (tempo) che funzionerà come avere l'immagine principale , non sarà mai bisogno di questo.

o devo solo creare un tavolo users di avere (50 x 25000) 1 250 000 gli utenti (e crescente).

Sto pensando alla prima opzione, però, io non sono sicuro di come avrei usato Entity Framework su tale disposizione ... Vorrei probabilmente bisogno di tornare indietro agli anni '90 e generare il mio livello di Data Logic a mano.

è che sarà una semplice chiamata a procedure magazzini contenenti l'azienda Id

  

Che cosa suggerisce?

L'applicazione del sistema sarà ASP.NET (probabilmente MVC, sto ancora cercando di capire questo fuori come tutta la mia conoscenza è il webforms, anche se ho visto video di Scott Hanselman MVC - Cuciture facile - ma so che non sarà così facile come i problemi verranno e mi ci vorrà più tempo per risolverli), oltre a Microsoft SQL .

Answer 1

Anche se hai descritto questo come un 1-molti, sarei ancora progettare il DB come molti-a-molti in guardia contro un cambiamento futuro in requisiti. Qualcosa di simile:

Answer 2

Dopo aver lavorato con un database multi-terabyte di SQL Server, e avere esperienza con centinaia di tavoli nel corso della mia carriera con il multi-milioni di righe, vi posso dire con piena certezza che SQL Server è in grado di gestire una tua company e users tavoli senza partizionamento. E 'sempre lì quando ne avete bisogno, ma la vostra preoccupazione non dovrebbe essere di circa le tabelle - scegliere lo schema più semplice che soddisfi le vostre esigenze. Se si vuole fare qualcosa per ottimizzare le prestazioni, il collo di bottiglia sarà quasi sicuramente i vostri dischi. Non comprare grandi, dischi lenti. Procuratevi un gruppo di piccoli, dischi elevato numero di giri e diffondere i dati fuori attraverso di loro il più possibile, e non i dischi condividere con i tuoi log e dati. Con i database, si è quasi sempre meglio ottenendo prestazioni con un buon hardware, un sottosistema di buon disco e corretta indicizzazione. Non compromesso e complicare lo schema cercando di anticipare le prestazioni - te ne pentirai. Ho visto veramente grandi database in cui era necessario questo genere di cose, ma la tua non è vero.

Answer 3

Re: Devo creare tabelle in base Aziende Sì

come

users_company_0001 users_company_0002 users_company_0003

no, come

companyID  companyName, contactID

o devo solo creare una tabella agli utenti di avere (50 x 25000) 1 250 000 utenti (e crescente) Sì

Answer 4

Penso che si dovrebbe creare tabelle separate per Società e per l'utente. Poi una terza tabella per collegare i due: CompanyAdmin. Qualcosa di simile:

• società ( company_id , company_name, ...)
• utente ( User_Id , User_name, ...)
• CompanyAdmin ( company_id , user_id)

In questo modo è possibile aggiungere gli utenti e / o aziende senza influenzare il numero di di tavoli è necessario gestire. E 'generalmente una cattiva progettazione in cui è necessario per modificare il database (es. aggiungere tabelle) quando giungeranno nuovi dati (aziende) al sistema.

Con una corretta indicizzazione, il join costi in un database contenente qualche milione di righe non dovrebbe essere un problema.

Infine, se mai hai bisogno di cambiare o registrare ulteriori informazioni su Le aziende, gli utenti o il rapporto tra loro, questa configurazione dovrebbe hanno il minor numero di impatto sulla vostra applicazione.