Classe di archiviazione SQLite ed efficienza di recupero - sql, sqlite, sqlite3

Supponiamo che io abbia una tabella, che è una tabella di riferimento (la tabella è stata solo consultata, non aggiornata).

ad esempio, lo schema della tabella:

CREATE TABLE countries(
zip_code INTEGER PRIMARY KEY,
name TEXT)

Voglio migliorare la velocità di recupero dei dati. Ora, sto usando index sul namecolonna, ma voglio andare oltre ...

Modifica lo schema della tabella:

CREATE TABLE countries(
zip_code INT PRIMARY KEY,
name CHAR(200))

ribadisco che ho modificato il tipo di dati delle colonne per specificare un file dimensione fissa per ogni colonna, quindi una dimensione fissa per l'intera riga.

È un'ipotesi corretta? Pensando quello righe di dimensione fissa sono recuperabili più rapidamente rispetto alle righe di dimensioni dinamiche in SQLite DBMS.

Mi ispiro ad altri DBMS (MySQL) che recuperano righe di dimensioni statiche più rapidamente rispetto alle righe di dimensioni dinamiche

risposte:

Sto correggendo questa risposta in modo che sia rilevante per SQLite. È accettata, quindi non posso cancellarla.

Non penso che immagazzini 200 byte per ciascunoname velocizzerà la tua query. Nella maggior parte dei database, tutto ciò che farà è moltiplicare il volume di dati che stai archiviando, perché i nomi sono più brevi. In SQLite, è un no-op. SQLite memorizza tutte le stringhe di caratteri come testo; non riempie i valori con spazi come fanno gli altri database.

Non ho familiarità con le parti interne di SQLite. Ma i database (incluso SQLite) memorizzano i record su pagine di dati. Questi sono gestiti da un meccanismo di memorizzazione nella cache. E gli indici identificano un record dalla pagina in cui si trova. Viene letta l'intera pagina di dati.

Nella maggior parte dei database, dichiarando una colonna come name(200) probabilmente sprecherebbe molto spazio. Aumenterebbe la dimensione del record e questo ha i seguenti effetti:

• È possibile memorizzare un numero inferiore di record su una singola pagina.
• È meno probabile che un recupero successivo trovi la pagina per il record nella cache.
• È probabile che la lettura dell'intera tabella occupi molto più spazio di memoria.
• La lettura di una riga richiede la lettura e l'elaborazione di più byte.

In SQLite, niente di tutto questo si applica, perché SQLite ignora semplicemente la lunghezza e non riempie il valore con spazi.

Quello che vuoi fare non è una buona idea nella maggior parte dei database e non ha alcun effetto su SQLite. Consiglierei di evitare un tale approccio. L'indice dovrebbe essere sufficiente.