Pugno, hai effettivamente identificato un problema reale? Puoi dimostrare che avere una tabella ampia causa qualche problema al sistema in termini di throughput, consumo di risorse, latenza o somesuch? La suddivisione della tabella causerà un sovraccarico di manutenzione, quindi è meglio accertarsi che sia giustificato.
We [sic] trying to think about db index size
La dimensione dell'indice è determinata dalle colonne chiave. Poiché la chiave non cambierà dopo la divisione, la dimensione dell'indice sarà la stessa. Nello specifico l'indice depth rimarrà lo stesso, ed è qui che entra in gioco un sacco di overhead. Inoltre, immagino che entrambe le tabelle avranno la stessa chiave (UserId?) Quindi il doppio del disco sarà usato per memorizzare l'indice.
Alcuni RDBMS implementano gli indici BTree in cui la foglia è l'intera riga. Per questi, la suddivisione della tabella consentirà di tenere più righe in una determinata quantità di RAM, migliorando le prestazioni. Tuttavia, non vedrai un miglioramento se il server DB non è sotto pressione di memoria, o la tabella utente viene toccata così frequentemente da non essere mai sfrattata dalla memoria al momento.
and things like caching as the user objects are cached in Redis.
Hai serializzato e messo in cache l'intero oggetto? Bene, fare meno lavoro è più veloce di fare più lavoro. Quindi spaccare è probabilmente vantaggioso. Ciò non richiede che la divisione venga eseguita nell'RDBMS, tuttavia, solo nel codice di gestione della cache Redis.
I know in some cases we'd need a couple of db queries to the get the data instead of a single one
Bene, forse. Una singola query può unirsi a molte tabelle e amp; restituire un singolo set di risultati. Una stored procedure può restituire più set di risultati. È possibile definire una vista che unisce le tabelle e la vista può essere referenziata dall'applicazione.
Ho l'impressione che sia coinvolto un ORM. Le tue opzioni qui potrebbero essere dettate da questo.
Uno dei principali inconvenienti della divisione è che ora hai due oggetti che assolutamente, sicuramente devono essere sincronizzati. Ciò richiederà codice di applicazione molto accurato o, più probabilmente, trigger di database. Questo complica il ragionamento sul sistema. Sarebbe mai accettabile avere un utente senza UserSettings corrispondenti? In quali circostanze può essere rimosso? Come imporre il vincolo della relazione "esattamente uno" tra le due tabelle? Questo è realizzabile ma richiede una pianificazione.