È possibile utilizzare i database SQLite come formato di interscambio dati, ma non è una soluzione particolarmente valida. Perché?
-
Stai cercando un formato di scambio dati compatto. Al contrario, l'obiettivo di SQLite è quello di archiviare i dati in un modo facilmente interrogabile e modificato su disco. Questo non è necessariamente un formato compatto, ad es. se il database contiene pagine libere.
-
Usando un formato leggibile non umano in cui è possibile accedere ai dati solo tramite l'interfaccia SQLite, si sta sacrificando una buona parte della debugabilità. Tra l'altro, i file SQLite, XML e JSON sono tutti auto-descrittivi, con SQLite e facoltativamente XML che contengono anche il loro schema di dati all'interno del documento.
-
SQLite ha una buona storia di compatibilità, ma versioni differenti hanno capacità diverse. Dovrai assicurarti che i file di database generati siano compresi da tutte le versioni SQLite supportate, che potrebbero richiedere configurazioni e test aggiuntivi.
-
Usando SQLite, sei vincolato al modello di dati di SQLite. Ciò significa che tutto si adatta a righe e colonne e viene digitato in modo dinamico. Altri formati di dati hanno modelli di dati più flessibili che sono più adatti a grafici di oggetti arbitrari. In particolare, XML ha anche un eccellente supporto per la definizione e il controllo degli schemi di dati.
Dato che stai prelevando dati da un database, lo schema dei dati dovrebbe approssimativamente adattarsi, ma nota che le estensioni specifiche del database potrebbero essere problematiche. Non è certamente il caso che qualsiasi dato in un database SQLite possa essere importato in un altro DB. Dato che dovrai necessariamente scrivere strumenti aggiuntivi per l'esportazione / importazione, scegliere SQLite su un altro formato di file non rappresenta una scorciatoia che ti farà risparmiare una notevole quantità di lavoro.
Nella maggior parte degli scenari, l'utilizzo di un formato di interscambio di dati stabilito è decisamente preferibile, il che spesso significa XML o JSON, o forse un formato binario come Protobuf. A meno che non si trasferiscano per lo più dati binari o dati che possono essere definiti con semplici strutture, la scelta non conta molto, basterà codificare in base64 qualsiasi dato binario prima di inserirlo in un formato testuale, che ti costa solo il 33%.
Il CSV potrebbe essere un'opzione per i dati tabulari, ma la maggior parte delle implementazioni CSV sono sottodescrittite e non sono d'accordo su dettagli come come delimitatori e newline possono essere sfuggiti, quindi fai molta attenzione a configurarlo correttamente.
Se è necessario combinare più documenti in un unico file, una strategia comune consiste nell'utilizzare un archivio ZIP come una busta. Sono facili da eseguire il debug con strumenti comuni e facili da manipolare a livello di programmazione. Per esempio. la strategia "ZIP di XML" viene utilizzata dai formati di file .docx e .odt.
Considerare inoltre se lo spostamento manuale dei dati tra due database sia la soluzione corretta per le proprie esigenze. La maggior parte dei DB ha il supporto integrato per una configurazione slave master + readonly. Potrebbe essere molto più facile. Se sposti i dati manualmente, dovrai anche pensare ai problemi di coerenza dei dati. Stai trasferendo una selezione di record o stai aggiornando il DB remoto completo? Stai trasferendo record o un registro delle modifiche applicate a questi record dall'ultima sincronizzazione? Come stai verificando che i dati trasferiti si traducano in una visione coerente, ad es. rispetto ai vincoli e alle relazioni con le chiavi esterne?
Quindi riassumendo: hai un problema difficile. L'uso di SQLite potrebbe essere possibile, ma non renderà più facile questo problema. Preferisci soluzioni consolidate.