Quali sono i vantaggi / gli svantaggi della creazione di un nuovo set di tabelle per ciascun utente?

È una pessima idea essere onesti e ci sono una serie di problemi immediati con cui mi viene in mente: -

• modificare la struttura della tabella diventa molto difficile a causa del numero di tabelle che devi modificare.
• devi concedere ai diritti dell'app la modifica della struttura della tabella che è opposta al principio del "privilegio minimo".
• stai mescolando la tua struttura dati con i tuoi dati reali che va contro la separazione delle preoccupazioni e mescola il design con i dati.
La migrazione
• non dovrebbe essere una preoccupazione importante, sebbene sia necessario accertarsi che i nomi delle tabelle siano univoci.

Tutto questo prima di entrare in qualsiasi problema di prestazioni o limiti sul numero di tabelle o considerare l'impatto di come l'indicizzazione e le viste saranno inutili su queste tabelle multiple.

È meglio non attenersi a:

Users
Transactions
Items
Tags

Potresti trovare alcune informazioni utili su come progettare correttamente le tue tabelle in È necessario creare un database con il minor numero possibile di tabelle

Non farlo . Semplice e chiaro, questo è un terribile modello di livello dati. Non va bene per i seguenti motivi:

• Non si adatta bene (le righe dovrebbero essere create con nuovi dati, non oggetti)
• I modelli di accesso ai dati ne risentiranno (sarà uno scenario doloroso, nel migliore dei casi, per costruire le query sui dati. Nel peggiore dei casi, si otterranno prestazioni estremamente scarse e altri possibili effetti collaterali)
• Non gestibile (sarà ancora una volta difficile trovare la creazione e la manutenzione su cose come indici e statistiche)
• Mancanza di rigidità dei dati (pensateci, non esiste un costrutto forzato per dire che tutte le tabelle user transaction avranno le stesse colonne, tipi di dati, ecc. Potreste trovarvi in un problema di consistenza / purezza dei dati abbastanza rapidamente)

Non ho nemmeno ideato il design relazionale e come questo non si abboni ai costrutti accettati lì. Ma si spera che l'incubo di supportabilità e programmabilità sia sufficiente per allontanarti da questa direzione.

Per non parlare ... è solo difficile . Perché renderlo più difficile per te, dal momento che il modello di tabelle comuni per dati comuni è così semplice e naturale .

La tua soluzione non è relazionale e presenta molti svantaggi, per citarne alcuni:

• quasi impossibile fare alcune query che riguardano dati per più utenti
• non è possibile utilizzare alcun vincolo, quindi nessuna coerenza dei dati
• difficile da gestire con i privilegi
• difficile da migrare (se l'ID utente è in qualche modo modificato, il gioco è fatto)

Probabilmente ci dovrebbero essere quelle tabelle:

• users , con id campo
• transactions , items e tags tabelle, tutte con user_id campo che punta a users.id - questo è chiamato "relazione uno-a-molti", poiché ciascun utente può avere più transazioni, articoli e tag .

Se, ad esempio, i tag possono essere condivisi tra gli utenti, dovresti avere tags table solo avere id , e anche una tabella users_tags con due campi: user_id e tag_id , che collega utenti e tag con relazione molti-a-molti.

Devi imparare almeno le basi della normalizzazione del database e RDBMS in generale, prima ancora di tentare di progettare uno schema. La progettazione del database è un argomento moderatamente difficile (in base all'attività), non qualcosa con cui è possibile iniziare in un paio di giorni.