Sembra che tu stia mettendo in discussione se hai bisogno di dividere la tabella master perché ci sono così tante colonne. La risposta breve è no. Toccherà una risposta più lunga di seguito.
In un modo semplice di guardare i database, si tratta di gruppi di dati e di ciò che questi gruppi rappresentano. Database relazionali che sono relazioni, o collegamenti, tra gruppi di dati. Quindi, quando pensi a ciò che accade in una tabella o in un gruppo di tabelle, stai elaborando aspetti di qualche "entità" attraverso i dati che rappresentano questa cosa. Come già sai, questo viene fatto con una tabella master e una o più tabelle figlio.
Ad esempio, un dipendente. Abbiamo un nome, dob, numero identificativo (i), indirizzo, numero di telefono, data di noleggio e così via. Alcune di queste cose sono 1 a 1, alcune sono da 1 a n. È così che generalmente scappiamo dove le cose vanno dal punto di vista del design. Questo ci dà una tabella principale e un certo numero di tabelle figlio.
La maggior parte dei database moderni non presenterà problemi con una tabella principale con un numero elevato di colonne. Dieci, venti, cento, nessuno se questo è importante per il database. Quindi, dal punto di vista del design logico, non c'è motivo di rompere questa tabella principale. Tuttavia, il mondo reale e la teoria non vanno d'accordo tutto il tempo. Devo sottolineare che questi tempi sono RARI, spesso un modo diverso di guardare i dati ti permetterà di esprimerlo in un modo diverso ed evitare il problema. Se ti accorgi di avere un numero enorme di colonne, chiedi perché sono lì e prova a guardarle da un altro punto di vista.
Torna all'esempio del dipendente, numero di telefono. Ci potrebbero essere diversi numeri qui. Quindi faccio una colonna per il telefono di casa un'altra per il cellulare e un'altra per l'estensione di lavoro? Potrei, o potrei fare un tavolo per bambini per questo. Quella tabella avrebbe tre campi, id, categoria, numero. Quindi, quelle che sembravano tre colonne nella tabella principale sono state effettivamente spostate in una tabella figlio. Stessi dati, modo diverso di guardarlo.
Penso che questo forse sia vicino a casa per il tuo caso, ma ammetto che sto indovinando qui. Potevo vedere una serie di statistiche che rappresentano un personaggio che sembra essere parte della tabella principale, ma in realtà potrebbero essere facilmente espressi come tabella figlio. Hai citato attributi e abilità di base, entrambi i quali avrebbero alzato una bandiera rossa per me se facevano parte della tabella principale. Ancora una volta, sto facendo alcune supposizioni basate sulle mie esperienze di rpg con computer e giochi di penna e carta. Man mano che il tuo gioco si evolve, potresti trovare una ragione per aggiungere una nuova abilità, potresti anche aggiungere un nuovo attributo di base. Puoi cambiare o eliminare un'abilità o un attributo base esistenti. Vuoi cambiare anche il tuo database? Idealmente, no non si desidera tornare indietro e modificare la struttura del database e quindi il codice per il livello del database e quindi il livello del codice logico di sistema e quindi il livello del codice dell'interfaccia utente. Volete modifiche del genere per influenzare il minor numero possibile di codice. Quindi, forse hai una tabella delle abilità, in cui ogni riga è un'abilità. Allo stesso modo, una tabella di attributi di base con ogni attributo come una riga. Nota che in questi casi dico riga non colonna, proprio come con il numero di telefono del dipendente.
Mi sento cominciando a divagare, quindi ora mi fermo.
Quindi, questa è una risposta più lunga. Per riassumere, no non è necessario suddividere una tabella principale perché ha molte colonne TUTTAVIA si desidera analizzare tali colonne per assicurarsi che non possano essere espresse in un altro modo, come le righe della tabella figlio.
Spero che ti aiuti.