Le tabelle del database MySQL devono avere una sola unità di informazioni per riga?

Question

Le tabelle del database MySQL devono avere una sola unità di informazioni per riga?

#1 da (9 voti)
#2 da (0 voti)

0

Gestisco un servizio automatico di raccolta dati sul lavoro, che registra misurazioni (temperature, tensioni, ecc.) da una dozzina di sensori ad una velocità di circa una volta al secondo. La tabella del database MySQL assomiglia a questo esempio fittizio:

TABLE: recorded_measurements
**************************************
id sensor       measurement timestamp
1  thermometer  75          1478360216
2  voltmeter    2           1478360216
3  ohmmeter     101         1478360216
4  thermometer  74          1478360217
5  voltmeter    2           1478360217
6  ohmmeter     103         1478360217

^{La tabella reale è ovviamente più complicata, tenendo conto delle unità e di altri dettagli, ma questo MWE è sufficiente per dimostrare la mia domanda.}

Gli utenti interrogano principalmente per sensore e finestra temporale, ad esempio Mostra tutte le tensioni negli ultimi 10 minuti o Ricevi tutte le temperature e le resistenze di ieri. Poiché ci sono centinaia di milioni di righe e la tabella viene interrogata frequentemente, abbiamo indicizzato il timestamp e le colonne del sensore.

Un nuovo membro del gruppo sta usando il mio lavoro per fare qualcosa di simile in un altro posto e ha ereditato la maggior parte del mio codice. Tuttavia, hanno impostato la tabella del database in modo diverso:

TABLE: recorded_measurements2
****************************************
timestamp   thermometer voltage ohmmeter
1478360216  75          2       101
1478360217  74          2       103

Il suo ragionamento è che rende più semplice l'interrogazione in base alla finestra temporale, dal momento che basta richiedere tutti i dati entro i limiti desiderati e filtrare le colonne richieste più tardi (in realtà ha circa 30 sensori). Credo che questo renderà le query più difficili a lungo termine, oltre che incredibilmente lente una volta che la tabella è stata compilata a sufficienza, oltre a utilizzare il timestamp UNIX come "chiave primaria" sembra orribile, anche se ho difficoltà a esprimere perché .

La mia domanda è: il mio collega sta violando qualsiasi principio di archiviazione di database ampiamente accettato, oppure sto semplicemente pensando a una sola traccia e sfavorevole a una soluzione di archiviazione dei dati altrettanto valida? Se è il primo, ci sono risorse seminali (documenti, studi di casi, post sui blog di riferimento) che posso condividere per supportare il mio reclamo?

programming-practices storage mysql database-design

posta user1717828 05.11.2016 - 17:29

fonte

2 risposte

Leggi altre domande sui tag programming-practices storage mysql database-design

È una costante o una variabile? Disattiva o Abilita funzionalità nell'applicazione C #

score 9 · Answer 1

Il tuo collega ha ragione su questo. Se stai prendendo le misure da tutti i tuoi sensori nello stesso intervallo e il set di sensori che stai registrando rimane costante o per lo più costante, ciò che dovresti registrare è le misurazioni di tutti i tuoi sensori ogni intervallo. Quello che stai facendo in questo momento, registrando un elemento per riga con un tag che spiega quale tipo di valore rappresenta l'elemento, è un noto anti-pattern noto come EAV (Entity-Attribute-Value.) L'entità, in questo caso, è il tuo tempo di lettura, con ogni sensore che rappresenta un attributo che ha un valore specifico.

L'EAV ritiene che offra molta flessibilità, e lo fa, ma lo fa eliminando molti importanti vantaggi del modello di database relazionale. Ad esempio:

non puoi utilizzare la colonna dei valori come FK ora, perché qui ci sono molti diversi tipi di valori misti
JOIN s diventa molto più doloroso se non impossibile
Tutte le ricerche per un tipo di valore coinvolgono un filtro WHERE , che è molto più costoso di un filtro SELECT
Per rendere quel WHERE meno costoso, hai dovuto aggiungere un indice sulla colonna Atttribute, che rende INSERT s più costoso e aumenta il lato del tuo database. Se ti sposti dal modello EAV al modello di tabella standard, lo ottieni gratuitamente come parte dello schema della tua tabella.

Il modello EAV può essere utile per dati non fissi che non si adattano facilmente a uno schema ben definito, ma non è quello con cui stai lavorando. Devi andare con il modello del tuo collega.

score 0 · Answer 2

Per archiviazione dei dati vorrei attenermi al tuo approccio o persino creare una tabella per un fatto di misura (se hai attributi per esso) e tabelle separate per tipo di misura se hai set diversi di attributi.

Ciò che il tuo collega sembra fare meglio è presentazione dei dati . Ma attraverso il cambiamento di archiviazione dei dati non sono d'accordo con. Fortunatamente i motori di database ci consentono di separare memoria e presentazione. Un paio di viste sulla parte superiore della tabella e una struttura simile alla tabella dei colleghi offrono vantaggi di entrambe le opzioni?

Riguardo al timestamp non è chiaro quale sia l'attributo dei dati di vita reale che rappresenta. Può fare abbastanza bene in molte situazioni ed essere un disastro negli altri.