Introduzione

Supponiamo che il Documento aperto e in particolare il formato OpenDocument Presentation "ODP", fossero costruiti attorno a SQLite. I vantaggi includerebbero:

  • Documenti più piccoli
  • Tempi di archiviazione/salvataggio più rapidi
  • Tempi di avvio più rapidi
  • Meno memoria utilizzata
  • Versione del documento
  • Una migliore esperienza utente

Si noti che questo è solo un esperimento di pensiero. Non stiamo suggerendo di cambiare OpenDocument. Questo articolo non è nemmeno una critica all'attuale design di OpenDocument. Lo scopo di questo saggio è quello di suggerire modi per migliorare i progetti dei formati di file futuri.

Informazioni su OpenDocument e sulla presentazione di OpenDocument

Il formato di file OpenDocument è utilizzato per le applicazioni d'ufficio: word processor, fogli di calcolo e presentazioni. È stato originariamente progettato per la suite OpenOffice, ma da allora è stato incorporato in altre suite di applicazioni desktop. L'applicazione OpenOffice è stata modificata e rinominata più volte. L'utilizzo principale di OpenDocument da parte di questo autore è la creazione di presentazioni di diapositive con NeoOffice su Mac, oppure LibreOffice su Linux e Windows.

Un file OpenDocument Presentation o "ODP" è un file di archivio ZIP contenente file XML che descrivono le diapositive della presentazione e file immagine separati per le varie immagini incluse nella presentazione. (I file di videoscrittura e di foglio elettronico OpenDocument sono strutturati in modo simile, ma non sono considerati in questo articolo). Il lettore può facilmente vedere il contenuto di un file ODP utilizzando il comando "zip -l". Ad esempio, il seguente è l'output di "zip -l" di una presentazione di 49 diapositive su SQLite del 2014 SouthEast LinuxFest 2014 conferenza:

Archive:  self2014odp
  Length      DateTime    Name
---------  ---------- -----   ----472014-06-2112:34   mimetype
        02014-06-2112:34   Configurations2/statusbar/02014-06-2112:34   Configurations2/accelerator/currentxml
        02014-06-2112:34   Configurations2/floater/02014-06-2112:34   Configurations2/popupmenu/02014-06-2112:34   Configurations2/progressbar/02014-06-2112:34   Configurations2/menubar/02014-06-2112:34   Configurations2/toolbar/02014-06-2112:34   Configurations2/images/Bitmaps/547022014-06-2112:34   Pictures/10000000000001F40000018C595A5A3Dpng
    462692014-06-2112:34   Pictures/100000000000012C000000A8ED96BFD9png
58 other pictures omitted130132014-06-2112:34   Pictures/10000000000000EE0000004765E03BA8png
  10050592014-06-2112:34   Pictures/10000000000004760000034223EACEFDpng
   2118312014-06-2112:34   contentxml
    461692014-06-2112:34   stylesxml
     10012014-06-2112:34   metaxml
     92912014-06-2112:34   Thumbnails/thumbnailpng
    387052014-06-2112:34   Thumbnails/thumbnailpdf
     96642014-06-2112:34   settingsxml
     97042014-06-2112:34   META-INF/manifestxml
---------                     -------1096100678 files

L'archivio ZIP ODP contiene quattro diversi file XML: content.xml, styles.xml, meta.xml e settings.xml. Questi quattro file definiscono il layout delle diapositive, il contenuto del testo e lo stile. Questa presentazione in particolare contiene 62 immagini, da quelle a tutto schermo a piccole icone, ciascuna memorizzata come file separato nella cartella Pictures. Il file "mimetype" contiene una singola riga di testo che dice:

application/vndoasisopendocumentpresentation

Lo scopo degli altri file e cartelle è attualmente sconosciuto all'autore, ma probabilmente non è difficile da capire.

Limitazioni del formato di presentazione OpenDocument

L'uso di un archivio ZIP per incapsulare i file XML e le risorse è un approccio elegante a un formato di file applicativo. È chiaramente superiore a un formato di file binario personalizzato. Ma usare un database SQLite come contenitore, invece dello ZIP, sarebbe ancora più elegante.

Un archivio ZIP è fondamentalmente un database chiave/valore, ottimizzato per il caso di write-once/read-many e per un numero relativamente piccolo di chiavi distinte (da qualche centinaio a qualche migliaio), ciascuna con un BLOB di grandi dimensioni come valore. Un archivio ZIP può essere visto come un database "a mucchio di file". Funziona, ma ha alcune carenze rispetto a un database SQLite, come quelle che seguono:

  1. L'aggiornamento incrementale è difficile.

    È difficile aggiornare le singole voci di un archivio ZIP. È particolarmente difficile aggiornare le singole voci di un archivio ZIP in modo da non distruggere l'intero documento se il computer perde la corrente e/o si blocca nel bel mezzo dell'aggiornamento. Non è impossibile farlo, ma è sufficientemente difficile che nessuno lo faccia. Invece, ogni volta che l'utente seleziona "File/Salva", l'intero archivio ZIP viene riscritto. Di conseguenza, l'operazione "File/Salva" richiede più tempo del dovuto, soprattutto su hardware datati. Le macchine più recenti sono più veloci, ma è comunque fastidioso che la modifica di un singolo carattere in una presentazione di 50 megabyte faccia consumare 50 megabyte della limitata vita di scrittura dell'unità SSD.

  2. L'avvio è lento.

    In linea con il tema della pila di file, OpenDocument memorizza tutti i contenuti delle diapositive in un unico grande file XML chiamato "content.xml". LibreOffice legge e analizza l'intero file solo per visualizzare la prima diapositiva. LibreOffice sembra anche leggere tutte le immagini in memoria, il che ha senso visto che quando l'utente fa "File/Salva" deve riscriverle tutte, anche se nessuna di esse è cambiata. L'effetto netto è che l'avvio è lento. Facendo doppio clic su un file OpenDocument viene visualizzata una barra di avanzamento anziché la prima diapositiva. Il risultato è un'esperienza negativa per l'utente. La situazione diventa sempre più fastidiosa con l'aumentare delle dimensioni del documento.

  3. È richiesta più memoria.

    Poiché gli archivi ZIP sono ottimizzati per memorizzare grandi quantità di contenuto, incoraggiano uno stile di programmazione in cui l'intero documento viene letto in memoria all'avvio, tutte le modifiche avvengono in memoria, quindi l'intero documento viene scritto su disco durante il comando "File/Salva". OpenOffice e i suoi discendenti abbracciano questo modello.

    Si potrebbe obiettare che, nell'era dei desktop multi-gigabyte, è giusto leggere l'intero documento in memoria. Ma non va bene. Innanzitutto, la quantità di memoria utilizzata supera di gran lunga la dimensione del file (compresso) su disco. Quindi una presentazione di 50 MB potrebbe richiedere 200 MB o più di RAM. Questo non è un problema se si modifica un solo documento alla volta. Ma quando si lavora a un discorso, l'autore di solito ha 10 o 15 presentazioni diverse attive contemporaneamente (per facilitare il copia/incolla di diapositive da presentazioni precedenti) e quindi sono necessari gigabyte di memoria. Se si aggiungono uno o due browser Web aperti e qualche altra applicazione desktop, il disco improvvisamente gira e la macchina si scambia. Anche un solo documento è un problema quando si lavora su un Chromebook economico equipaggiato con Ubuntu. Usare meno memoria è sempre meglio.

  4. Il recupero in caso di crash è difficile.

    I discendenti di OpenOffice tendono ad andare in segfault più spesso dei concorrenti commerciali. Forse per questo motivo, i fork di OpenOffice eseguono backup periodici dei loro documenti in memoria, in modo che gli utenti non perdano tutte le modifiche in sospeso quando si verifica l'inevitabile crash dell'applicazione. Ciò causa frustranti pause nell'applicazione per i pochi secondi in cui ogni backup viene eseguito. Dopo il riavvio da un arresto anomalo, all'utente viene presentata una finestra di dialogo che lo guida nel processo di ripristino. La gestione del ripristino degli arresti anomali in questo modo comporta un sacco di logica aggiuntiva per l'applicazione ed è generalmente un fastidio per l'utente.

  5. Il contenuto è inaccessibile.

    Non è possibile visualizzare, modificare o estrarre facilmente il contenuto di una presentazione OpenDocument utilizzando strumenti generici. L'unico modo ragionevole per visualizzare o modificare un documento OpenDocument è aprirlo utilizzando un'applicazione specificamente progettata per leggere o scrivere OpenDocument (leggi: LibreOffice o uno dei suoi cugini). La situazione potrebbe essere peggiore. È possibile estrarre e visualizzare singole immagini (ad esempio) da una presentazione utilizzando solo lo strumento di archiviazione "zip". Ma non è ragionevole cercare di estrarre il testo da una diapositiva. Ricordate che tutti i contenuti sono memorizzati in un unico file "context.xml". Questo file è XML, quindi è un file di testo. Ma non è un file di testo che può essere gestito con un normale editor di testo. Per la presentazione di esempio qui sopra, il file content.xml è composto esattamente da due righe. La prima riga del file è semplicemente:

    <?xml version="1.0" encoding="UTF-8"?>

    La seconda riga del file contiene 211792 caratteri di XML impenetrabile. Sì, 211792 caratteri tutti su una riga. Questo file è un buon test per un editor di testo. Per fortuna il file non è un oscuro formato binario, ma in termini di accessibilità potrebbe anche essere scritto in Klingon.

Primo miglioramento: Sostituire ZIP con SQLite

Supponiamo che invece di usare un archivio ZIP per memorizzare i suoi file, OpenDocument usi un database SQLite molto semplice con il seguente schema a tabella singola:

CREATETABLE OpenDocTree(
  filename TEXTPRIMARYKEY,-- Name of file
  filesize BIGINT,-- Size of file after decompression
  content BLOB-- Compressed file content);

Per questo primo esperimento, non viene cambiato nulla del formato dei file. OpenDocument è ancora un mucchio di file, solo che ora ogni file è una riga in un database SQLite anziché una voce in un archivio ZIP. Questa semplice modifica non sfrutta la potenza di un database relazionale. Tuttavia, questa semplice modifica mostra alcuni miglioramenti.

Sorprendentemente, l'uso di SQLite al posto di ZIP rende il file di presentazione più piccolo. Davvero. Si potrebbe pensare che un file di database relazionale sia più grande di un archivio ZIP, ma almeno nel caso di NeoOffice non è così. Di seguito è riportato uno screen-scrape che mostra le dimensioni della stessa presentazione di NeoOffice, sia nel formato originale dell'archivio ZIP generato da NeoOffice (self2014.odp), sia in quello riconfezionato come database SQLite utilizzando il file SQLAR :

-rw-r--r--  1 drh  staff  10514994 Jun  8 14:32 self2014.odp-rw-r--r--  1 drh  staff  10464256 Jun  8 14:37 self2014.sqlar-rw-r--r--  1 drh  staff  10416644 Jun  8 14:40 zip.odp

Il file del database SQLite ("self2014.sqlar") è circa il mezzo per cento più piccolo dell'equivalente file ODP! Come è possibile? A quanto pare la logica di generazione degli archivi ZIP in NeoOffice non è così efficiente come potrebbe essere, perché quando lo stesso mucchio di file viene ricompresso usando l'utilità "zip" della riga di comando, si ottiene un file ("zip.odp") ancora più piccolo, di un altro mezzo punto percentuale, come si vede nella terza riga qui sopra. Quindi, un archivio ZIP ben scritto può essere leggermente più piccolo di un database SQLite equivalente, come ci si aspetterebbe. Ma la differenza è minima. Il risultato principale è che un database SQLite è competitivo in termini di dimensioni con un archivio ZIP.

L'altro vantaggio dell'uso di SQLite al posto di ZIP è che il documento può essere aggiornato in modo incrementale, senza il rischio di corromperlo se si verifica una perdita di corrente o un altro incidente nel mezzo dell'aggiornamento. (È vero che tutto il contenuto è ancora conservato in un unico grande file XML ("content.xml") che deve essere completamente riscritto se cambia anche un solo carattere. Ma con SQLite, solo quel file deve essere modificato. Gli altri 77 file del repository possono rimanere inalterati. Non devono essere riscritti tutti, il che rende l'esecuzione di "File/Save" molto più veloce e risparmia l'usura delle unità SSD.

Secondo miglioramento: Dividere il contenuto in pezzi più piccoli

Una pila di file incoraggia a memorizzare il contenuto in pochi grandi pezzi. Nel caso di ODP, ci sono solo quattro file XML che definiscono il layout di tutte le diapositive di una presentazione. Un database SQLite permette di memorizzare le informazioni in pochi grandi pezzi, ma SQLite è anche abile ed efficiente nel memorizzare le informazioni in numerosi pezzi più piccoli.

Quindi, invece di memorizzare tutti i contenuti di tutte le diapositive in un unico file XML sovradimensionato ("content.xml"), supponiamo che ci sia una tabella separata per memorizzare i contenuti di ogni diapositiva separatamente. Lo schema della tabella potrebbe essere simile a questo:

CREATETABLE slide(
  pageNumber INTEGER,-- The slide page number
  slideContent TEXT-- Slide content as XML or JSON);CREATEINDEX slide_pgnum ON slide(pageNumber);-- Optional

Il contenuto di ogni diapositiva potrebbe ancora essere memorizzato come XML compresso. Ma ora ogni pagina è memorizzata separatamente. Quindi, quando si apre un nuovo documento, l'applicazione potrebbe semplicemente eseguire:

SELECT slideContent FROM slide WHERE pageNumber=1;

Questa query restituirà in modo rapido ed efficiente il contenuto della prima diapositiva, che potrà essere analizzato e visualizzato rapidamente dall'utente. Per visualizzare la prima schermata è necessario leggere e analizzare una sola pagina, il che significa che la prima schermata viene visualizzata molto più rapidamente e non è più necessaria una fastidiosa barra di avanzamento.

Se l'applicazione volesse mantenere tutto il contenuto in memoria, potrebbe continuare a leggere e analizzare le altre pagine utilizzando un thread in background dopo aver disegnato la prima pagina. Oppure, dato che la lettura da SQLite è così efficiente, l'applicazione potrebbe scegliere di ridurre l'occupazione di memoria e tenere in memoria solo una singola diapositiva alla volta. Oppure potrebbe tenere in memoria la diapositiva corrente e quella successiva, per facilitare le transizioni rapide alla diapositiva successiva.

Si noti che la suddivisione del contenuto in parti più piccole tramite una tabella SQLite offre flessibilità all'implementazione. L'applicazione può scegliere di leggere tutto il contenuto in memoria all'avvio. Oppure può leggere solo alcune pagine in memoria e tenere il resto su disco. Oppure può leggere in memoria una sola pagina alla volta. E versioni diverse dell'applicazione possono fare scelte diverse senza dover apportare modifiche al formato del file. Tali opzioni non sono disponibili quando tutto il contenuto è contenuto in un unico grande file XML in un archivio ZIP.

La suddivisione del contenuto in parti più piccole aiuta anche a velocizzare le operazioni di file/salvataggio. Invece di dover riscrivere il contenuto di tutte le pagine quando si effettua un File/Save, l'applicazione deve riscrivere solo le pagine che sono state effettivamente modificate.

Un piccolo svantaggio della suddivisione del contenuto in parti più piccole è che la compressione non funziona altrettanto bene sui testi più brevi e quindi la dimensione del documento potrebbe aumentare. Tuttavia, dato che la maggior parte dello spazio del documento viene utilizzato per memorizzare le immagini, una piccola riduzione dell'efficienza di compressione del contenuto testuale sarà difficilmente percepibile e rappresenta un piccolo prezzo da pagare per una migliore esperienza utente.

Terzo miglioramento: Il versionamento

Una volta che ci si sente a proprio agio con il concetto di memorizzazione separata di ogni diapositiva, il supporto della versione della presentazione è un piccolo passo. Si consideri il seguente schema:

CREATETABLE slide(
  slideId INTEGERPRIMARYKEY,
  derivedFrom INTEGERREFERENCES slide,
  content TEXT-- XML or JSON or whatever);CREATETABLE version(
  versionId INTEGERPRIMARYKEY,
  priorVersion INTEGERREFERENCES version,
  checkinTime DATETIME,-- When this version was savedcommentTEXT,-- Description of this version
  manifest TEXT-- List of integer slideIds);

In questo schema, invece di avere un numero di pagina che determina l'ordine di ogni diapositiva all'interno della presentazione, ogni diapositiva ha un identificatore intero unico che non è correlato alla sua posizione nella sequenza. L'ordine delle diapositive nella presentazione è determinato da un elenco di ID diapositiva, memorizzato come stringa di testo nella colonna MANIFEST della tabella VERSION. Poiché sono consentite più voci nella tabella VERSION, ciò significa che è possibile memorizzare più presentazioni nello stesso documento.

All'avvio, l'applicazione decide innanzitutto quale versione visualizzare. Poiché il versionId aumenterà naturalmente nel tempo e di norma si vuole vedere la versione più recente, una query appropriata potrebbe essere:

SELECT manifest, versionId FROM version ORDERBY versionId DESCLIMIT1;

O forse l'applicazione preferisce utilizzare il checkinTime più recente:

SELECT manifest, versionId,max(checkinTime)FROM version;

Utilizzando una singola query come quella sopra descritta, l'applicazione ottiene un elenco degli ID delle diapositive per tutte le diapositive della presentazione. L'applicazione quindi interroga il contenuto della prima diapositiva, lo analizza e lo visualizza come prima.

(A parte: Sì, la seconda query qui sopra che utilizza "max(checkinTime)" funziona davvero e restituisce una risposta ben definita in SQLite. Una query di questo tipo restituisce una risposta non definita o genera un errore in molti altri motori di database SQL, ma in SQLite fa quello che ci si aspetta: restituisce il manifest e il versionId della voce che ha il checkinTime massimo).

Quando l'utente fa "File/Salva", invece di sovrascrivere le diapositive modificate, l'applicazione può ora creare nuove voci nella tabella SLIDE solo per le diapositive che sono state aggiunte o modificate. Quindi crea una nuova voce nella tabella VERSIONE contenente il manifesto modificato.

La tabella VERSION mostrata sopra ha colonne per registrare un commento di check-in (presumibilmente fornito dall'utente) e l'ora e la data in cui si è verificata l'azione File/Save. Registra anche la versione padre per registrare la storia delle modifiche. Forse il manifesto potrebbe essere memorizzato come un delta dalla versione madre, anche se in genere il manifesto è abbastanza piccolo da rendere la memorizzazione di un delta più problematica che utile. La tabella SLIDE contiene anche una colonna derivedFrom che potrebbe essere usata per la codifica delta se si decide che salvare il contenuto della diapositiva come delta della versione precedente è un'ottimizzazione utile.

Con questa semplice modifica, il file ODP ora memorizza non solo la modifica più recente della presentazione, ma anche una cronologia di tutte le modifiche storiche. L'utente normalmente vorrebbe vedere solo l'edizione più recente della presentazione, ma se lo desidera può andare indietro nel tempo per vedere le versioni storiche della stessa presentazione.

In alternativa, è possibile memorizzare più presentazioni all'interno dello stesso documento.

Con uno schema di questo tipo, l'applicazione non avrebbe più bisogno di effettuare backup periodici delle modifiche non salvate in un file separato, per evitare di perdere il lavoro in caso di crash. Al contrario, potrebbe essere allocata una versione speciale "in attesa" e le modifiche non salvate potrebbero essere scritte nella versione in attesa. Poiché dovrebbero essere scritte solo le modifiche, e non l'intero documento, il salvataggio delle modifiche in sospeso comporterebbe solo la scrittura di pochi kilobyte di contenuto, e non di più megabyte, e richiederebbe millisecondi anziché secondi, per cui potrebbe essere fatto frequentemente e silenziosamente in background. In questo modo, quando si verifica un crash e l'utente si riavvia, tutto (o quasi) il suo lavoro viene conservato. Se l'utente decide di eliminare le modifiche non salvate, può semplicemente tornare alla versione precedente.

Qui ci sono dei dettagli da riempire. Forse si può prevedere una schermata che visualizzi la cronologia delle modifiche (magari con un grafico) e che consenta all'utente di selezionare la versione che desidera visualizzare o modificare. Forse è possibile fornire una funzione per unire le biforcazioni che potrebbero verificarsi nella cronologia delle versioni. E forse l'applicazione dovrebbe fornire un mezzo per eliminare le versioni vecchie e indesiderate. Il punto chiave è che l'uso di un database SQLite per memorizzare il contenuto, piuttosto che un archivio ZIP, rende tutte queste caratteristiche molto, molto più facili da implementare, il che aumenta la possibilità che alla fine vengano implementate.

E così via...

Nelle sezioni precedenti abbiamo visto come il passaggio da un archivio chiave/valore implementato come archivio ZIP a un semplice database SQLite con solo tre tabelle possa aggiungere funzionalità significative a un formato di file applicativo. Si potrebbe continuare a migliorare lo schema con nuove tabelle, con l'aggiunta di indici per le prestazioni, con trigger e viste per la comodità della programmazione e con vincoli per imporre la coerenza dei contenuti anche in presenza di errori di programmazione. Ulteriori idee di miglioramento includono:

  • Memorizzare uno stack di annullamento/ripristino automatico in una tabella del database, in modo che l'annullamento possa tornare indietro nelle sessioni di modifica precedenti.
  • Aggiungere funzionalità di ricerca full text nella presentazione o in più presentazioni.
  • Decomposizione del file "settings.xml" in una tabella SQL più facilmente visualizzabile e modificabile da applicazioni separate.
  • Suddividere le "Note del presentatore" da ogni diapositiva in una tabella separata, per facilitare l'accesso da applicazioni e/o script di terze parti.
  • Migliorare il concetto di presentazione al di là della semplice sequenza lineare di diapositive, per consentire di fare delle escursioni e dei percorsi secondari a seconda di come il pubblico sta rispondendo.

Un database SQLite ha molte capacità, che questo saggio ha solo iniziato a sfiorare. Ma si spera che questo rapido sguardo abbia convinto alcuni lettori che l'uso di un database SQL come formato di file applicativo merita una seconda occhiata.

Alcuni lettori potrebbero opporsi all'uso di SQLite come formato di file applicativo a causa di una precedente esposizione ai database SQL aziendali e alle avvertenze e limitazioni di questi altri sistemi. Ad esempio, molti motori di database aziendali sconsigliano di memorizzare stringhe o BLOB di grandi dimensioni nel database e suggeriscono invece di memorizzare stringhe e BLOB di grandi dimensioni come file separati e di memorizzare il nome del file nel database. Ma SQLite non è così. Ogni colonna di un database SQLite può contenere una stringa o un BLOB di dimensioni fino a circa un gigabyte. E per stringhe e BLOB di 100 kilobyte o meno, le prestazioni di I/O sono migliori rispetto all'uso di file separati.

Alcuni lettori potrebbero essere riluttanti a considerare SQLite come formato di file applicativo perché sono stati inculcati con l'idea che tutti gli schemi di database SQL devono essere fattorizzati in terza forma normale e memorizzare solo piccoli tipi di dati primitivi come stringhe e numeri interi. Certamente la teoria relazionale è importante e i progettisti dovrebbero sforzarsi di comprenderla. Ma, come dimostrato in precedenza, è spesso accettabile memorizzare informazioni complesse come XML o JSON nei campi di testo di un database. Fate quello che funziona, non quello che il vostro professore di database vi ha detto di fare.

Rassegna dei vantaggi dell'uso di SQLite

In sintesi, l'affermazione di questo saggio è che usare SQLite come contenitore per un formato di file applicativo come OpenDocument e memorizzare molti oggetti più piccoli in quel contenitore è molto meglio che usare un archivio ZIP con pochi oggetti più grandi. Per intenderci:

  1. Un file di database SQLite è approssimativamente della stessa dimensione, e in alcuni casi più piccolo, di un archivio ZIP contenente le stesse informazioni.

  2. Le funzionalità di aggiornamento atomico di SQLite consentono di scrivere in modo sicuro piccole modifiche incrementali nel documento. Questo riduce l'I/O totale del disco e migliora le prestazioni di File/Salva, migliorando l'esperienza dell'utente.

  3. Il tempo di avvio viene ridotto consentendo all'applicazione di leggere solo il contenuto mostrato per la schermata iniziale. Questo elimina in gran parte la necessità di mostrare una barra di avanzamento quando si apre un nuovo documento. Il documento viene visualizzato immediatamente, migliorando ulteriormente l'esperienza dell'utente.

  4. L'impronta di memoria dell'applicazione può essere ridotta drasticamente caricando solo i contenuti rilevanti per la visualizzazione corrente e mantenendo il grosso dei contenuti su disco. La rapidità di interrogazione di SQLite rende questa soluzione una valida alternativa al mantenimento di tutto il contenuto in memoria in ogni momento. Inoltre, quando le applicazioni utilizzano meno memoria, l'intero computer diventa più reattivo, migliorando ulteriormente l'esperienza dell'utente.

  5. Lo schema di un database SQL è in grado di rappresentare le informazioni in modo più diretto e sintetico rispetto a un database chiave/valore come un archivio ZIP. Questo rende il contenuto del documento più accessibile alle applicazioni e agli script di terze parti e facilita funzioni avanzate come il versioning integrato del documento e il salvataggio incrementale del lavoro in corso per il ripristino dopo un crash.

Questi sono solo alcuni dei vantaggi dell'uso di SQLite come formato di file per applicazioni, quelli che sembrano più in grado di migliorare l'esperienza utente di applicazioni come OpenOffice. Altre applicazioni potrebbero trarre vantaggio da SQLite in modi diversi. Consultate il documento Formato di file applicativo per ulteriori idee.

Infine, ribadiamo che questo saggio è un esperimento di pensiero. Il formato OpenDocument è ben consolidato e già ben progettato. Nessuno crede davvero che OpenDocument debba essere cambiato per usare SQLite come contenitore invece di ZIP. Questo articolo non è nemmeno una critica a OpenDocument per non aver scelto SQLite come contenitore, dato che OpenDocument è precedente a SQLite. Lo scopo di questo articolo è piuttosto quello di usare OpenDocument come esempio concreto di come SQLite possa essere usato per costruire formati di file applicativi migliori per i progetti futuri.