MYSQL, usando nomi di tabella univoci VS usando id

Question

Al momento ho 26 tabelle in un database MYSQL. Il mio capo vuole che ricreare quelle 26 tabelle ogni volta che abbiamo un nuovo client e aggiungere un'abbreviazione client di qualche tipo a quelle nuove tabelle. Ad esempio, ci sono utenti company1 ~ system ~ e utenti company2 ~ system ~ e così via e così via.

Preferirei solo aggiungere una tabella al database che tenga traccia dei nostri clienti, con una chiave primaria INT a 11 cifre con incremento automatico e fare riferimento invece nelle altre 26 tabelle, quindi non stiamo ingombrando il database con 4000 tabelle se hanno 200 client.

Penso che la sua paura sia che se seguiamo il metodo che preferirei fare, MYSQL impiegherà notevolmente più tempo per eseguire query perché i client con un numero di record compreso tra 2000 e 5000 ciascuno condivideranno le tabelle. Quindi, ad esempio, la ricerca di utenti appartenenti a company1 da una tabella denominata system ~ utenti con 1.500.000 record sarebbe più lenta della ricerca di utenti da una tabella denominata company1 ~ system ~ utenti con 2.000 record. Penso che in realtà sarebbe più lento per MYSQL cercare se ogni client che abbiamo ha 26 set di tabelle (26 per client).

Quale metodo è effettivamente più lento?

Answer 1

Perché non creare semplicemente un database o ogni azienda? E quindi non è nemmeno necessario creare nomi di tabella dinamici durante la costruzione delle query. È una soluzione molto più solida. Inoltre, renderà i dati dei clienti più separati, quindi ogni interdipendenza sarà probabilmente più ovvia.

Quanto sopra funziona meglio quando anche i livelli dell'applicazione sono separati in modo da poter fornire a ciascuna istanza un diverso set di credenziali di accesso al database.

In caso contrario, potrebbe funzionare correttamente o essere scomodo o corretto a seconda dell'installazione, della piattaforma in uso e così via.

L'aggiunta di un nome di società è un trucco ma può essere fatto funzionare, immagino.

Anche avere un ID client nei record è un approccio comune. Non mi preoccuperei necessariamente di circa 1,5 milioni di record dal punto di vista delle prestazioni, purché le tabelle siano opportunamente indicizzate. Questa non è un'enorme quantità di record. Inoltre, i criteri di identificazione dell'azienda dovrebbero limitare i risultati abbastanza bene comunque.

Answer 2

200 client * 5.000 record [in una data tabella] è piccolo per gli standard del database. Se aggiungi l'ID client come prima chiave della maggior parte degli indici, lo schema che suggerisci non dovrebbe introdurre alcun degrado delle prestazioni evidente.

Tuttavia, potrebbe essere interessante mantenere separati i dati dei clienti per altri motivi. Forse se questo ha senso per quanto riguarda l'applicazione, è possibile gestire i dati di ciascun client in un database separato.

Answer 3

Se si dispone di indici appropriati sull'identificatore dell'azienda, le prestazioni non dovrebbero essere un problema.

Per quanto riguarda l'aggiunta di un ID ai nomi delle tabelle, perché non prendere in considerazione la creazione di un'istanza di database separata? Penso che cambiare i nomi delle tabelle possa richiedere una codifica aggiuntiva (per generare dinamicamente i nomi delle tabelle su qualsiasi query), dove l'utilizzo di istanze diverse sembra semplice.

Answer 4

Conserva tutti i dati dei tuoi clienti nella stessa serie di tabelle fino a quando non avrai una buona ragione per farlo.

Da quanto ho capito da quanto sopra, i tuoi dati sono incredibilmente piccoli quindi si adatteranno in ram; questo in pratica rende superfluo l'ottimizzazione delle prestazioni, quindi non ti preoccuperai di cose come il clustering degli indici.

Fai la cosa più semplice che potrebbe funzionare. Conservali in un set di tabelle.

Answer 5

Grazie a tutti per i vostri suggerimenti meravigliosi e utili. Dal consenso generale tra di voi sembra che dovrei separare ogni serie di tabelle di client nel loro database o consentire ai client di condividere le loro informazioni in una serie di tabelle con indici appropriati con identificatori di società.

Answer 6

La tua soluzione suona meglio e per quanto riguarda le prestazioni, l'hardware è economico. Cercare di mantenere 4000 tabelle o 26 database, probabilmente costerà di più rispetto al singolo colpo di una CPU più bella con più RAM. Sembra che il tuo capo stia cercando di fare l'ingegneria per te, non va bene.