Dovrebbero essere 3 tabelle SQL o una?

Question

Questa è una nuova domanda che è nata da questa domanda

A causa delle risposte, la natura della domanda è cambiata, quindi penso che pubblicare una nuova sia ok (?).

Di seguito puoi vedere il mio progetto DB originale. Ho 3 tabelle e ora ho bisogno di una query per ottenere tutti i record per un utente specifico per i calcoli di running_balances.

• Le transazioni sono tra utenti, come il credito reciproco. Quindi le unità vengono scambiate tra utenti.
• Le inventarizzazioni sono cose fisiche introdotte nel sistema; un utente ottiene unità per questo.
• I consumi sono materiali fisici consumati; un utente deve pagare unità per questo.

|--------------------------------------------------------------------------|
|  type     |  transactions       |  inventarizations  |  consumations     |
|--------------------------------------------------------------------------|
|  columns  |  date               |  date              |  date             |
|           |  creditor(FK user)  |  creditor(FK user) |                   |
|           |  debitor(FK user)   |                    |  debitor(FK user) |
|           |  service(FK service)|                    |                   |
|           |                     |  asset(FK asset)   |  asset(FK asset)  |
|           |  amount             |  amount            |  amount           |
|           |                     |                    |  price            |
|--------------------------------------------------------------------------|

(Si noti che 'importo' è in unità diverse; queste sono le voci e i calcoli vengono effettuati su tali importi. Al di fuori dell'ambito per spiegare il perché, ma questi sono i campi).

La domanda è: " Può / dovrebbe essere presente in una tabella o essere più tabelle (come ho per ora)? " Mi piace la soluzione a 3 tavoli perché ha semanticamente più senso. Ma poi ho bisogno di un'istruzione select così complicata (con risultati di performance forse negativi) per running_balances. La domanda originale nel link sopra ha chiesto questa affermazione, qui sto chiedendo se il design del db è appropriato (mi scuso con quattro doppie pubblicazioni, spero sia ok).

Answer 1

Questa stessa domanda sorge quando si tenta di implementare un sistema di contabilità generale per la contabilità a partita singola. Quello che hai chiamato " transazioni " corrisponde a "trasferimenti", come dal risparmio al controllo. Quello che hai chiamato "inventarizzazioni" corrisponde a "reddito", come il deposito di una busta paga. Quello che hai chiamato " consumazioni " corrisponde a "spese", ad esempio quando si paga la bolletta elettrica. L'unica differenza è che nella contabilità, tutto è stato ridotto al valore del dollaro (o altra valuta). Quindi non devi preoccuparti di identificare le risorse, perché un dollaro è buono come un altro.

Quindi sorge la domanda se è necessario disporre di colonne separate per "importo di addebito" e "importo del credito" o in alternativa, se puoi avere solo una colonna per "importo" e inserire un numero positivo per gli addebiti e un importo negativo per i crediti. Sostanzialmente si pone la stessa domanda se si sta implementando la contabilità a partita doppia anziché la contabilità a partita singola.

In termini di aritmetica interna e gestione interna dei dati, le cose sono molto più semplici quando si adotta l'approccio a colonna singola. Ad esempio, per verificare se una determinata transazione è in pareggio, tutto ciò che devi fare è chiedere se la somma (importo) è uguale a zero.

Le complicazioni sorgono quando le persone richiedono il tradizionale formato di contabilità per i moduli di immissione dei dati, il recupero delle schermate e i rapporti pubblicati. Il formato tradizionale richiede due colonne separate, contrassegnate con "Addebito" e "Credito", che contengono solo numeri positivi o vuoti, con il vincolo che ogni articolo deve avere una voce in debito o credito ma non entrambi, e l'altra colonna deve essere lasciata vuota. Queste trasformazioni richiedono una certa quantità di programmazione tra il formato esterno e il formato interno.

È davvero una questione di scelta. È meglio mantenere il tradizionale formato di contabilità dei creditori di debito e credito affiancati o è meglio passare a un formato che utilizza numeri negativi in ??modo significativo? Ci sono alcune circostanze che favoriscono ciascuna di queste scelte progettuali.

Nel tuo caso, dipenderà da come intendi utilizzare i dati. Costruirei prototipi con ciascuno dei due progetti e poi inizierei a lavorare sull'elaborazione CRUD fondamentale per ciascuno. Qualunque sia la soluzione più semplice nel tuo ambiente è quella da scegliere.

Answer 2

Hai detto che l'importo sarà unità diverse, quindi penso che dovresti tenere ogni tavolo per sé.

Personalmente odio un progetto di DB che ha "regole diverse" per riempire una tabella in base al tipo di entità memorizzata in una riga. Diventa solo disordinato ed è difficile mantenere vivi i tuoi vincoli su un tavolo del genere.

Crea semplicemente una vista indicizzata che risponda alle domande del tuo saldo per mantenere le tue domande "semplici"

Answer 3

Non esiste una risposta definitiva a questo e le risposte dipenderanno in gran parte dalle metodologie di progettazione del database adottate dal risponditore.

Il mio consiglio sarebbe di provare entrambi i modi e vedere quale ha il miglior compromesso tra query, prestazioni e manutenzione / usabilità.

Puoi sempre impostare una vista che restituisca tutte e 3 le tabelle come un'unica tabella per l'interrogazione e abbia un campo type per il tipo di processo a cui una riga si riferisce.