Crea il database per adattare i dati e rende i dati adatti al database

Mantieni le cose piccole e semplici.

Hai menzionato che il tuo file di testo contiene molti dati che non ti servono. Se tutto ciò è contenuto nel tuo database, avrai una struttura molto più complicata / difficile da comprendere che la prossima persona dovrà decifrare.

Riesci a immaginare di ereditare una grande struttura complicata in cui solo il 10% è in uso?

Vedi anche questa domanda SO e l'articolo del blog di Jeff Atwood, Coding for Violent Psychopaths

Con tutti i mezzi, inserisci le cose che ti servono. Segui le migliori pratiche di database, normalizza entro limiti ragionevoli, utilizza visualizzazioni, chiavi esterne e indici e proteggi gelosamente l'integrità dei dati con una vendetta.

Non creare un sacco di spazzatura "di cui potresti aver bisogno un giorno".

YAGNI è tuo amico.

Sembra molto che tu stia facendo un progetto ETL. Hai tutti e tre gli attributi: hai il tuo estratto (estrai i dati dal file in arrivo), trasforma (unendo i dati con il file di ieri) e hai un carico in mySQL. In effetti, hai persino ottenuto segnalazioni (le tue cose di Excel).

Ci sono intere società (come Informatica) che hanno creato prodotti intorno a rendere facile ciò che stai facendo. Se questo è un tipo di cosa una tantum che non vedi alcun segno di crescita in sempre più fonti di dati, allora con tutti i mezzi dovresti seguire i suggerimenti degli altri in questa discussione - più semplice è meglio. Tuttavia , se questo è solo il primo di molti di questi progetti, devi proprio a te stesso per imparare informazioni sul data warehousing, ETL, reporting - Business Intelligence in generale. La maggior parte dei magazzini inizia come piccoli progetti di tipo one-off come i tuoi, e poi crescono e crescono fino a quando i tuoi piccoli programmi personalizzati diventano completamente ingombranti e ingestibili da una prospettiva di operazioni / corsa. A quel punto le aziende iniziano a parlare di "fare sul serio" il loro magazzino, il che significa che iniziano a standardizzare i processi per fare ciò che si sta facendo (avere una cassetta, avere un livello di staging, avere uno strato standard / di base, avere posti definiti) per fare carichi e lasciare cose nei file, ecc.)

Faccio regolarmente questo tipo di cose, per una grande organizzazione finanziaria.

Direi che il tuo # 2 è quasi perfetto, tranne per la parte "database umano". Rendilo leggibile, certo, ma prioritizza PARSEABLE. Anche Excel è il formato di output sbagliato, anche se potresti sicuramente creare materiale Excel dal tuo formato di output (ad esempio, crea CSV, quindi costruisci quello che vuoi).

Diciamo che i tuoi record assomigliano a questo:

S: 1 T COCA COLA P = 20 V = 1000

S: 2 Q B = 23 S = 24 FANTA

S: 1 T FANTA P = 24 V = 1000

S: 2 Q B = 24 S = 26 FANTA

Diciamo che vuoi estrarre tutti i record Q e trovare i valori B massimi, per ogni marca. Quindi FANTA = 26, basato su quanto sopra.

Per prima cosa, devi trovare i record giusti. Sta solo leggendo i dati e cercando una nuova riga seguita da "S:", leggendo la riga successiva e leggendo fino alla prossima nuova riga, se quella riga successiva era Q.

Quindi, dividi il record in base alle nuove righe, trova la riga che inizia con S = e analizza il resto in un valore. Hai anche bisogno del marchio, che è solo il quinto campo, nella tua lista di elementi che sono stati separati da nuove righe.

Infine, devi solo mantenere una mappa dei marchi e i loro valori massimi visti finora. Ogni volta che vedi un nuovo valore per un marchio, controlla se è superiore al valore precedente per quella marca. Se lo è, aggiorna il valore.

La parte critica è: quando lo fai, SCRIVI UN ALTRO SEMPLICE, PARZABILE, FILE DI TESTO, o ancora, forse CSV, a patto che i tuoi dati siano abbastanza semplici da mappare il CSV senza perdita di dati.

Il mio formato di output per questo sarebbe semplice come:

FANTA = 26

Niente di più, niente di meno. Ma certo, scambia quello = per una virgola e chiamala CSV se vuoi. YAML / JSON sono anche pratici formati, quando necessario. Il punto è: mantienilo il più semplice possibile.

Scrivi quei dati in un file che si trova accanto al tuo file di input originale.

In questo modo, ottieni nuovi dati al giorno e si espandono sui vecchi dati, che si trovano in un file proprio accanto a quello. Quindi hai aggiunto valore, ma non hai aumentato la complessità.

Questa è una differenza fondamentale, ponendo, per esempio, tutte le informazioni dietro ad alcune API del database, o mostrandole in qualche GUI java, che non è facilmente accessibile per riepilogare alla fine dell'anno.

Se i requisiti cambieranno in futuro (cosa che fanno sempre) ti conviene avere un DB abbastanza normalizzato in base ai valori dell'identificatore (ad esempio ID cliente, ID ordine ..) Assicurandoti di avere un sound design di base per iniziare, sarai considerato un genio quando dici "sì, possiamo farlo".

Un database relazionale ben progettato avrà generalmente tabelle create per l'archiviazione ottimale dei dati. Naturalmente ci possono essere delle eccezioni a seconda del tuo scenario (praticamente ogni database con cui ho lavorato è stato denormalizzato a un certo punto), ma devi sempre cercare di favorire la struttura dei dati forzata con un facile recupero dei dati. Ciò renderà i tuoi dati più sicuri e più difficili da corrompere.

Dato che hai menzionato che stai usando mysql , views sarà tuo amico se desideri semplificare il recupero dei dati. Le viste sono query riutilizzabili eseguite sulla parte superiore della tabella o di altre viste. Puoi avere tutto ciò che ti serve e non influirà in alcun modo su come sono strutturati i tuoi dati.