Memorizza cronologia nella colonna del database SQL

1

Abbiamo un database che memorizza il processo / la cronologia di particolari macchine. Ciò che intendo è che abbiamo "avviato", "aggiornato", "spento" e così via per tutti i computer dell'azienda.

L'esigenza è di avere la cronologia disponibile nell'ordine corretto. Abbastanza semplice Il mio approccio era di avere una semplice tabella di database come questa:

counter  | machine | time | process | ...
 1       | PC1     | ...  | started 
 2       | PC2     | ...  | updating
 1       | PC1     | ...  | updating

La query sarà molto semplice perché posso semplicemente ordinare per contatore.

I miei colleghi hanno suggerito un approccio molto diverso. Il mio istinto dice che è sbagliato, ma non ho argomenti sufficienti contro di esso. Puoi aiutarmi a definire cosa c'è di sbagliato in questo?

Invece di usare più righe per il processo di una macchina, vogliono scriverle in sequenza nello stesso campo. Lo stesso vale per il campo del tempo. La loro argomentazione principale è che salviamo lo spazio di archiviazione

counter  | machine | time        | process | ...
 1       | PC1     | ... ... ... | started updating shutdown
 2       | PC2     | ... ... ... | started updating
    
posta Jasper 21.05.2014 - 17:16
fonte

3 risposte

6

Il secondo approccio produce risultati ambigui: qual è il valore nella colonna time ? il tempo di started ? o shutdown ? o qualcos'altro?

Il secondo approccio rende inoltre più difficile interrogare macchine che hanno un processo started e updating e nessun processo shutdown , che potrebbe essere utile per creare report e monitoraggio dal vivo. Certo, potresti utilizzare like... , ma tende ad essere più lento rispetto a quando puoi abbinare esattamente un valore, e anche più lentamente se indicizzi la colonna, o semplicemente memorizzi un ID che fa riferimento a un nome di processo.

Il secondo approccio potrebbe salvare un po 'di spazio, ma quanti dati hai intenzione di avere? Milioni di nuovi record ogni pochi giorni? Di Più? A meno che lo storage non sia un problema serio anche in questa fase di progettazione, non utilizzerei il secondo approccio.

    
risposta data 21.05.2014 - 17:25
fonte
2

Questa è una buona idea, supponendo che il tuo fornitore di database non abbia dimensioni massime del campo di testo. Potrei anche vedere che ci sono problemi di concorrenza sulle righe quando due thread stanno cercando di accodarsi alla stessa riga vicino allo stesso tempo.

Chiedete al vostro team perché lo spazio è un problema che proveremmo a fare cattive ottimizzazioni, risparmiando pochissimo spazio rispetto ai problemi che potrebbero causare.

    
risposta data 21.05.2014 - 17:24
fonte
2

Il primo metodo è migliore. Il secondo metodo avrà bisogno di una colonna senza limite di lunghezza. A meno che entrambi non conoscano i caratteri massimi che verranno inseriti.

Il secondo metodo non ti consentirà di monitorare il processo, passo dopo passo come il primo.

    
risposta data 21.05.2014 - 18:01
fonte

Leggi altre domande sui tag