Un'ampia tabella o più tabelle tematiche?

3

Sto provando a progettare un database per un semplice gioco basato sul testo in cui i personaggi dei giocatori hanno un gran numero di statistiche che voglio tracciare. Attualmente ho alcuni gruppi di statistiche, abilità, finanze, attributi di base e pochi altri. Ci sono alcuni campi che sono 1 a 1 con un personaggio che mi portano al seguente dilemma di progettazione: metto tutti questi campi 1 a 1 in una tabella molto ampia o li divido in tabelle a cui sono presenti temi il loro gruppo?

Se metto tutti i campi in una tabella, sto osservando una tabella con almeno 20 colonne, potenzialmente più quando si presentano più funzioni. Questo mi darebbe solo un posto dove andare per informazioni sul personaggio e renderebbe molto facile il caricamento dei dati nell'applicazione. Tuttavia, immagino che aggiornare i record in una tabella così grande sarebbe una seccatura dato che dovrei assicurarmi che l'aggiornamento di un campo non interrompa il resto dei dati.

Se dividessi i dati avrei 3 o 4 tabelle collegate dall'ID personaggio, ognuna con non più di 10 colonne. Credo che questo renderebbe i dati più facili da vedere dal punto di vista del visualizzatore di dati e gli aggiornamenti sarebbero meno volatili, ma quando devo raccogliere tutte le informazioni sui giocatori devo fare più query alle diverse tabelle.

Sono curioso di sapere cosa ne pensano quelli con più esperienza nel database design. Ho letto un po 'sulla normalizzazione del database ma sembra focalizzarsi sulla suddivisione dei dati a cui si aggiungono le relazioni invece dei dati che vanno da 1 a 1. Se fa la differenza sto usando il codice del framework Entity di ASP.NET per creare il database in SQL Server Express.

    
posta Evan Frisch 14.11.2015 - 16:42
fonte

2 risposte

1

Currently I have a few groups of related statistics, skills, finances, basic attributes, and a few others.

Beh, in realtà dipende. Ho evidenziato la parola chiave nella tua frase.

Se quei gruppi sono davvero "gruppi", perché non dividerli in tabelle? Ma la ragione non dovrebbe essere "perché la tabella è diventata grande" (almeno quando le prestazioni non sono ancora la tua preoccupazione principale), ma perché le vedi come gruppi, che possono essere elaborati indipendentemente su .

La divisione dei dati tra le tabelle rallenta l'accesso (poiché per aggregarlo occorrono diverse query). Ma ti dà la possibilità di lavorare in modo indipendente su questi dati, per vederli, valutarli e svilupparli in modo indipendente.

    
risposta data 16.11.2015 - 14:33
fonte
0

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.

    
risposta data 15.11.2015 - 21:08
fonte