Come gestite piccoli set di dati?

Question

Con insiemi di dati veramente piccoli, la politica in cui lavoro è generalmente quella di inserirli in file di testo, ma nella mia esperienza questo può essere un mal di testa di sviluppo. I dati generalmente provengono dal database e, in caso contrario, il processo coinvolto nell'impostazione / archiviazione è generalmente nascosto nel codice. Con il database puoi generalmente vedere tutti i dati a tua disposizione e le modalità con cui si collega ad altri dati.

A volte per insiemi di dati veramente piccoli li conservo in una struttura di dati interna nel codice (come un hash di Perl) ma poi, quando è necessaria una modifica, è nelle mani di uno sviluppatore.

Quindi, come gestite piccoli gruppi di dati modificati di rado? Hai impostato i criteri per quando utilizzare una tabella di database o un file di testo o ...?

Sono tentato di usare una tabella di database per tutto, ma non sono sicuro che ci siano implicazioni in questo.

Modifica: per contesto:

Mi è stato chiesto di mettere un nuovo modulo di contatto sul sito Web per una manciata di aziende, con altre da aggiungere occasionalmente in futuro. Tranne, le aziende non hanno indirizzi e-mail di contatto .. gli utenti all'interno di queste aziende hanno (mentre pubblicano lavori attraverso i propri account). Ora, però, vogliamo un'applicazione "speculativa" digitare funzionalità e il modulo richiede un indirizzo e-mail a cui inviare queste applicazioni. Ma non vogliamo anche inserire un indirizzo e-mail come proprietà nel modulo, altrimenti gli spammer possono semplicemente usarlo come gateway e-mail aperto. Quindi, chiaramente, abbiamo bisogno di un ID - > tipo di relazione contact_email con le aziende.

SO, posso aggiungere una colonna a una tabella con milioni di righe che verranno utilizzate, letteralmente, circa 20 volte O creare una nuova tabella che al massimo conterrà circa 20 righe. In genere il modo in cui lo gestiamo in passato è solo quello di creare un brutto file di testo e leggerlo da lì. Ma questo crea incubi di manutenzione e questi file di testo vengono spesso controllati quando i dati da cui dipendono cambiano. Forse questo è un difetto del processo, ma sono solo interessato a sentire opinioni su questo.

Answer 1

Se si tratta di piccoli dati di configurazione, utilizzo un formato semplice e comune. ini, json e yaml di solito sono ok. Ai fan di Java e .NET piace anche XML. in breve, usa qualcosa che puoi facilmente leggere su un oggetto in memoria e dimenticartene.

Answer 2

Inseriscilo nel database. Se cambia di rado, memorizzalo nella cache di livello intermedio.

Answer 3

L'esempio che viene subito in mente è ciò che è appropriato aver archiviato come enumerazione e ciò che è appropriato aver archiviato in una "ricerca". tabella del database.

Tendo a "disegnare la linea" con la regola che se si tradurrà in una colonna nel database contenente un "numero magico" che si associa a un valore di enumerazione, quindi l'enumerazione dovrebbe realmente esistere come tabella di ricerca. Se non è correlato ai dati memorizzati nel database (ad es. Dati di configurazione dell'applicazione anziché dati generati dall'utente), allora è un elenco completo.

Answer 4

Sicuramente dipende dall'utente dello strumento software che hai sviluppato per consumare l'insieme di dati, indipendentemente dalle dimensioni?

Potrebbe essere che conoscano Excel, quindi il tuo strumento dovrebbe analizzare un file .csv che creano.

Se è scritto per gli sviluppatori, a chi importa cosa usi. Tuttavia, non sono un fan dei database ingombranti con dati minori o transitori.

Answer 5

Abbiamo un formato di file di configurazione standard (chiave: valore) e una classe per gestirlo. Lo usiamo solo su tutti i progetti. Principalmente stiamo solo impostando proprietà persistenti per le nostre applicazioni (sviluppo di telefoni cellulari), quindi è una cosa appropriata da fare. YMMV

Answer 6

Nei casi in cui il programma accede a un database, memorizzerò tutto lì: più facile per il backup e lo spostamento dei dati.

Per i piccoli programmi senza accesso al database, conservo i miei dati nelle impostazioni .net, che sono memorizzati in un file xml - ovviamente questa è una funzione di c #, quindi potrebbe non essere applicabile a te.

Ad ogni modo, mi assicuro di archiviare tutti i dati in un unico posto. Di solito un database.

Answer 7

Hai considerato sqlite ? È basato su file, il che risolve la tua sensazione che "solo un file potrebbe fare" (configurazione zero), ma è un database perfettamente funzionante e si ridimensiona notevolmente. Supporta numerose API e ci sono numerosi front-end per la gestione.

Answer 8

Lo aggiungerei al database nella tabella principale:

1. Backup e ripristino (vuoi ripristinare questo file di testo, giusto?)
2. Interrogazione ad hoc (dal momento che puoi farlo sarà uno strumento SQL e lo unirà agli altri dati del database)
3. Se la colonna del database è vuota, i requisiti del negozio devono essere minimi (nulla se è una colonna NULL alla fine della tabella in Oracle)
4. Sarà più semplice se si desidera disporre di più server applicazioni in quanto non sarà necessario conservare più copie di alcuni file di configurazione extra
5. Metterlo in un tavolino per bambini complica solo il design senza dare reali benefici

Potresti già andare alla stessa riga nel database come parte dell'elaborazione, quindi è probabile che le prestazioni non siano un problema. In caso contrario, è possibile memorizzarlo nella memoria.