Abbiamo un database che supporta un'applicazione iOS e Android i cui dati primari sono un semplice campo di testo. Abbiamo uno strumento di compilazione che crea il database - prendendo un file txt grezzo che è un formato dati personalizzato, che assomiglia a:
---
.id SOME_ID
.author AUTHOR_NAME
.field MORE_DATA
.data_title TITLE
Data data data [#tag, #tag, ...]: some more data
Field: [id] description of data; [id] description
Examples:
- e.x. some example describing the entry
- e.x. another example
Closing field: more data; more data
---
o qualcosa del genere.
Per creare il database, è stato implementato un parser per prelevare il file txt raw, applicare alcune trasformazioni / ottimizzazioni per risparmiare spazio di archiviazione (ad esempio comprimere voci simili) e quindi convertirlo in un formato binario. La voce risultante è memorizzata in un formato simile ma compresso nel database, anche come campo di testo non elaborato che chiameremo entry_data nella tabella entries .
Tutti i consumatori del database, poiché i dati sono memorizzati essenzialmente nello stesso formato, anche devono implementare un parser molto simile, ma per il formato compresso in entry_data . Ciò significa che Android e iOS hanno entrambi circa 20-30 file che gestiscono l'analisi, nonché l'app Web che i dipendenti utilizzano per aggiornare il database.
Credo che il motivo iniziale per questo formato personalizzato sia dovuto alla facilità di aggiunta per le persone che lavorano sul database, nonché per motivi di spazio di archiviazione (non sono sicuro, ma penso che 6-8 anni fa i dispositivi mobili avevano limiti bassi sulla memoria disponibile). In ogni caso, il database è solo di circa 8 MB compressi, ma è diviso in diversi blocchi, probabilmente anche per evitare restrizioni sui limiti delle dimensioni dei file su dispositivi molto vecchi, che non supportiamo nemmeno più.
Il problema più grande con questo formato personalizzato è che anche piccole modifiche, come l'aggiunta di campi, provocano una cascata di modifiche attraverso lo strumento web utilizzato dalle persone che lavorano sul database, lo strumento di creazione del database, così come tutti i clienti. Quindi, se vogliamo aggiungere un campo category , dobbiamo apportare modifiche ai parser in 4 diverse basi di codice, tutte in lingue diverse (JavaScript, Java e Objective-C).
Tutte le nostre relazioni di dati possono essere modellate con un database relazionale. Non c'è motivo di includere esempi nella voce: gli esempi potrebbero essere facilmente collegati tramite una tabella di join entry_examples . Ci sono molti altri campi che hanno dati duplicati tra le voci, che potrebbero anche essere risolti con semplici chiavi esterne.
Il mio altro pensiero è che lo spazio di archiviazione dei dati è molto meno un problema nei dispositivi moderni - se perdere la complessa compressione gonfia il nostro database da 8 MB a 32 MB, che è quello che hanno molte altre app della stessa categoria ( o anche molto di più), non credo che gli utenti se ne dispiaceranno, soprattutto se il passaggio a un formato dati standard ci consente di aggiungere funzionalità nelle app più rapidamente.
Ha senso avere formati di dati personalizzati come il nostro, quando ci sono formati standard ampiamente adottati per i dati (ad es. struttura relazionale in database relazionali, o anche database NoSQL che hanno le voci come JSON strutturato)?