Mantenendo una colonna del rapporto è la divisione tra altre due colonne

3

Sto per creare una tabella SQL in cui voglio memorizzare gli ordini di valuta. Ciò significa che devo memorizzare quanto ho pagato per una certa quantità e il rapporto tra le due quantità. Quindi per esempio:

+-------------+--------------+-------+
| Quantity US | Quantity EUR | Ratio |
+-------------+--------------+-------+
|         250 |          200 | 1.25  |
+-------------+--------------+-------+

La mia domanda è: ha senso avere una colonna che memorizza un valore che sarà sempre la divisione tra due colonne, o è una pratica migliore per non archiviare quella nel DB e invece fai i calcoli ogni volta che ho bisogno del rapporto?

    
posta Antrim 03.02.2016 - 10:56
fonte

4 risposte

3

In questo caso, non sembra che abbia senso - il calcolo è semplice, veloce e facilmente realizzabile nel codice dell'applicazione (o persino in SQL).

Aggiungere la colonna significa che è necessaria la memorizzazione per esso, i costi di I / O ecc. ... Qual è l'analisi costi / benefici che devi fare qui.

Se il calcolo fosse qualcosa ad alta intensità di CPU, denormalizzare come descriveresti avrebbe senso, in particolare se devi ordinare per questa colonna.

    
risposta data 03.02.2016 - 11:05
fonte
2

Dipende.

Un po 'di ridondanza è consentita se viene fornito con benefici prestazionali misurati. E questo è se e solo se hai davvero bisogno di quell'aumento di prestazioni, ovvero se è un collo di bottiglia nella tua applicazione.

Quindi è davvero così difficile calcolare il rapporto nel tuo codice? Nel tuo esempio specifico, non mi sembra che la ridondanza aggiuntiva sia giustificabile. Nella mia esperienza è molto raro avere una buona ragione per aggiungere colonne ridondanti.

In conclusione, da quello che ho letto nella tua domanda, no, non dovresti aggiungere quella colonna. Anche se forse non conosco l'intera storia.

Inoltre, come altri hanno menzionato, puoi sempre utilizzare colonne calcolate ( in MySQL chiamato colonne generate ) se si è veramente intenzionati a risolverlo nel database.

    
risposta data 03.02.2016 - 11:04
fonte
1

A mio parere, non sono proprio i dati che devono essere archiviati. Se hai fatto di archiviarlo, naturalmente, c'è la complicazione che il rapporto dovrebbe essere ricalcolato nel caso in cui uno qualsiasi dei valori sottostanti cambi. In qualunque modo tu faccia questo sarà disordinato - sia con stored procedure o trigger ecc.

Non dici come questo si inserisca nel sistema in generale, ma potresti semplicemente derivare la colonna per uno standard CRUD scenario nella lettura dell'SP o magari creare una visualizzazione per calcolarla al volo.

    
risposta data 03.02.2016 - 12:13
fonte
1

Il rapporto è una colonna derivata che può essere calcolata. Memorizza il valore nel database solo per motivi di prestazioni. Se le tue domande sono lente. Altrimenti non memorizzare la colonna derivata nel database.

Se non hai intenzione di memorizzare il valore nel database, che sembra il più ragionevole nel tuo caso, ti consiglio le seguenti due opzioni:

1. Se il calcolo è semplice, puoi utilizzare una vista:

CREATE VIEW orders_view AS

SELECT QtyUS, QtyEU, QtyUS/QtyEU Ratio

FROM orders

2. Se il calcolo è complesso, puoi utilizzare una vista e una stored procedure:

CREATE VIEW orders_view AS

SELECT QtyUS, QtyEU, GetRatio(QtyUS,QtyEU) Ratio

FROM orders

Se il valore deve essere memorizzato nel database, consiglio vivamente l'uso di trigger di inserimento / aggiornamento del database per l'aggiornamento della colonna derivata. In questo modo garantirai il 100% di correttezza dei dati.

    
risposta data 03.02.2016 - 17:09
fonte

Leggi altre domande sui tag