Una tabella per tutte le transazioni VS. Tabella per ogni utente

I tuoi argomenti a favore di table-per-user sono sbagliati:

• Every user is isolated

Questo tipo di isolamento ha senso solo se si crea un utente DB per ogni utente e si lascia che eseguano direttamente query SQL sul proprio database. Di solito non lo fai, ma invece crei un'API per le query predefinite. Quell'API dovrebbe fare l'isolamento, non una separazione delle tabelle ...

• MariaDB can query faster

Non proprio. Se si definiscono gli indici correttamente, MariaDB può eseguire facilmente ed efficientemente query specifiche dell'utente. Se si programma correttamente, il table-per-utente genererà effettivamente query più lente perché:

1. Non potrai utilizzare i parametri di query per specificare l'utente.
2. Quindi dovrai costruire una stringa di comando SQL di ogni query per ogni utente.
3. Pertanto la tua connessione al database non sarà in grado di memorizzare le query nella cache.

• Easy data analysis

Perché? perché non devi scrivere WHERE user_id = 1234 ? Ma ora devi scrivere transactions_1234 , che potrebbe sembrare un po 'più semplice, ma è solo perché stiamo scrivendo SQL direttamente - in pratica l'ID utente verrà memorizzato in una variabile, quindi dovrai scrivere "... transactions_" + userId + "... invece di WHERE user_id = @user_id (e imposta l'ID utente usando i parametri di istruzione preparati).

E anche se scrivi direttamente SQL, una tabella per tutti gli utenti ha altri vantaggi che possono aiutare con l'analisi:

• Puoi creare viste che ti aiuteranno con l'analisi. Le viste possono avere un campo user_id da cui puoi filtrare, e MariaDB sarà in grado di fare quel filtro in modo efficiente. Con la tabella per utente dovresti creare una vista per ogni utente, che è molto meno gestibile, anche se non cambi mai la struttura dei dati, vorrai modificare le viste o creare nuove viste.

• Puoi creare funzioni SQL che ricevono user_id come argomento.

Inoltre, quando apri il workbench per eseguire quell'analisi, vuoi veramente vedere 10.000 tabelle nell'elenco delle tabelle?

Pretty much what every other dev would do

Perché è la cosa giusta da fare.

what if i have 100.000 transactions

Con l'indicizzazione corretta, non è molto.

MariaDB would have to do much more work

I database non sono fogli di calcolo. Non tengono in memoria l'intero tavolo e lo scannerizzano in sequenza [spesso].

La maggior parte delle tue 100.000 righe non verrà mai caricata nella memoria del server; si siederanno su disco fino a quando non vi si accede, tramite i propri indici. Le corrette strategie di indicizzazione si prenderanno cura dei tuoi [percepiti] problemi di rendimento.

MariaDB can query faster

Sì, può interrogare una singola tabella più velocemente, ma prima deve individuare quella tabella, il che significa leggere attraverso le tabelle del catalogo di sistema. Inoltre, è ancora necessario index ogni e ogni tabella, il che significa che il sistema viene bloccato con almeno un indice (probabilmente più) su tutte le 100.000 tabelle.

what if 10.000 users have a table?

Quindi ci vorrà più tempo per trovare ogni tabella nei cataloghi di sistema.

E stai ignorando il problema spinoso di quei casi in cui fai vuoi scansionare tra i dati di ogni dell'utente (per esempio, trovando chi ha un account in uscita) .

La suddivisione dei dati in questo modo rende le query come molto più difficili di quelle che devono essere.

I will never change the structure

Sì, lo farai.
Potrebbe non essere per un po 'di tempo, ma tu sarà .

I will enhance the security

Gli utenti non dovrebbero accedere direttamente a questi dati; solo attraverso l'applicazione che fornisci loro, che si prenderà cura di assicurare che gli utenti possano vedere solo ciò che dovrebbero vedere.