SQLite

Informasjon

Utviklet av	D. Richard Hipp
Første versjon	August 2000
Siste versjon	3.36.0 (18. juni 2021)
Innskudd	www.sqlite.org/src
Skrevet i	VS
Operativsystem	Multiplatform
Les formater	SQLite database filformat ( d ) , SQLite 3.x database ( d ) og SQLite rollbak journal ( d )
Skriftlige formater	SQLite databasefilformat ( d ) , SQLite 3.x database ( d ) , SQLite Zipvfs komprimert database ( d ) og SQLite rollbak journal ( d )
Type	Innebygd databasestyringssystem ( d )
Tillatelse	Offentlig domene
Nettsted	sqlite.org

SQLite (uttalt [ ɛs.ky.ɛl.ajt ]) er et bibliotek skrevet på språk C som tilbyr motor for relasjonell database tilgjengelig språk SQL . SQLite implementerer i stor grad SQL-92 standard-og ACID-egenskapene .

I motsetning til tradisjonelle databaseservere MySQL eller PostgreSQL , er dens particularity ikke å gjengi vanlig klient-server- ordningen , men for å være direkte integrert i programmene . Hele databasen (erklæringer, tabeller, indeks og data) lagres i en fil uavhengig av plattformen .

D. Richard Hipp , skaper av SQLite, har valgt å plassere dette biblioteket og kildekoden i det offentlige området , noe som tillater ubegrenset bruk i både åpen kildekode og proprietære prosjekter . Skaperen og noen av hovedutviklerne av SQLite er ansatt i det amerikanske selskapet Hwaci .

SQLite er den mest brukte databasemotoren i verden, takket være bruken:

i mange forbruker programvare som Firefox , Skype , Google Gears ,
i visse produkter fra Apple , Adobe og McAfee ,
i standardbibliotekene til mange språk som PHP eller Python .

På grunn av sin ekstreme letthet (mindre enn 600 KiB ) er det også veldig populært på innebygde systemer , spesielt på de fleste moderne smarttelefoner og nettbrett : iOS , Android og Symbian mobile operativsystemer bruker det som en database. Totalt kan vi telle mer enn en milliard kjente og rapporterte eksemplarer av biblioteket.

Historisk

D. Richard Hipp og en kollega begynte å designe SQLite tidlig på 2000 mens de jobbet i General Dynamics , da under kontrakt med den amerikanske marinen . SQLite skulle brukes i guidede raketter , for å erstatte IBM Informix- databaser som kjører på HP-UX- maskiner . Hovedmålet var å klare seg uten installasjon eller administrasjon: installasjonen eller oppdateringen av databasen kan ta en hel dag.

I august 2000 ble den første versjonen av SQLite utgitt. Hun brukte gdbm ( GNU Database Manager) for å manipulere B-trær .

SQLite 2.0 fjerner avhengigheten av gdbm og legger til transaksjonsstøtte.

SQLite 3.0, produsert ved hjelp av AOL , ble utgitt i 2004 og legger blant annet til regionalisering (med sortering og Unicode-støtte ) og typedeklarasjon.

Kjennetegn

Innebygd database

De fleste databaseforvaltningssystemer er bygget i henhold til den klient-server- paradigmet , dvs. en klientprogramvarebibliotek er integrert og brukes i en eller flere applikasjoner, mens den databasemotoren er i gang. I sin egen utførelse plass, eller til og med på en annen maskin, som IT-avdeling .

Tvert imot er SQLite direkte integrert i applikasjonen som bruker programvarebiblioteket, med databasemotoren. Tilgang til en database med SQLite gjøres ved å åpne filen som tilsvarer den: hver database lagres i en fil som er spesifikk for den, med dens erklæringer, tabeller og indekser, men også dens data.

Denne egenskapen gjør SQLite interessant som et alternativ til tekstfiler, brukt som et middel til integrert lagring i mange applikasjoner ( parametere , historie , cache ...), fordi det gjør tilgang til data raskere, sikrere, mer strukturert, enklere og fullstendig uavhengig av plattformen , mens det ikke påvirker enkel distribusjon av applikasjonen som bruker den.

Fjerning av mellommannen mellom applikasjon og data reduserer også datatilgangsforsinkelsen sammenlignet med systemer som bruker klient-serverparadigmet.

Imidlertid utgjør denne arkitekturen flere problemer:

Når et stort antall klienter får tilgang til den samme databasen, hvis en av klientene begynner å lese en del, er hele databasen låst skriftlig for de andre klientene, og omvendt hvis en av klientene begynner å skrive til en del, er hele databasen blokkert for lesing for andre klienter. Sistnevnte blir deretter satt på vent i løpet av denne tidsperioden, noe som kan være moteffektiv;
det er veldig komplisert å distribuere belastningen på flere maskiner: bruken av et filsystem i nettverket genererer ventetider og betydelig trafikk, fordi basen må lastes inn på nytt hos kunden hver gang den åpnes. Dette problemet er enda viktigere med nettsteder der databasen åpnes for hver forespurte side. I tillegg kan det oppstå feil i synkroniseringen av fillåser som kan tillate samtidig skriving til to forskjellige klienter på samme del av databasen og dermed føre til korrupsjon i databasen;
med store databaser er det ikke mulig å dele databasen i flere deler eller filer for å distribuere belastningen på flere maskiner. Noen filsystemer, som FAT 32 , har en maksimal filstørrelse som raskt kan begrense utvidelsen av en database.

Det er ingen spesifikk utvidelse for SQLite-databasefiler, men det er vanlig å støte på utvidelser som .sqlite eller .db , noen ganger etterfulgt av versjonsnummeret til biblioteket ( .sqlite3 , .db2 , etc.). Det er mulig å bruke en database bare lagres i RAM uten å skape database fil på disken, via den spesielle filnavnet : minne: .

Generelt er det tilrådelig å bruke SQLite der dataene ikke er sentraliserte og hvor utvidelsen av størrelsen på databasen sannsynligvis ikke blir kritisk. Hvis formålet med databasen er å sentralisere en stor datamengde og levere den til et stort antall klienter, er det å foretrekke å bruke DBMS basert på klient-server-paradigmet. SQLite er ment å erstatte tekstfiler, ikke tradisjonelle databaseservere.

Kompilator og virtuell maskin

Når et SQL-spørsmål sendes til SQLite gjennom programmeringsgrensesnittet , kompileres det før det kjøres.

Kompilatorens sequencer deler kommandoene gitt i deler som kan behandles separat (et forespørsel og dets underforespørsel for eksempel), som sendes til parseren som tar seg av å bryte ned spørringene i forskjellige objekter som representerer de forskjellige ordrene. klausuler i SQL-språket. Disse objektene sendes til kodegeneratoren som skaper en mellomkode på lavt nivå, eller bytekode .

Den resulterende koden er et sett med instruksjoner (137 forskjellige instruksjoner) kalt OpCodes . Dette lanseres i SQLites virtuelle maskin, som ser dem som små programmer som beskriver datasøk-, lese- og modifikasjonsoperasjoner.

Når den virtuelle maskinen tolker disse instruksjonene, ringte hun leder av B-tree basert på lag lavere nivå som skjuler den sider platen og Hardware Abstraction Layer .

Rettighetsadministrasjon

SQLite integrerer ikke styring av tilgangsrettigheter og modifisering av data. Administrasjonen utføres av filsystemet til operativsystemet : hvis filen som inneholder databasen ikke er skrivbar for en bruker, vil brukeren også kunne endre postene og den grunnleggende datastrukturen.

Rettighetsadministrasjon med GRANT og REVOKE er derfor ikke eksisterende, selv om disse er en del av SQL-92- spesifikasjonen .

Å bruke en SQLite-database krever ingen installasjons- eller konfigurasjonsprosedyre.

Bærbarhet

Biblioteket er skrevet helt i C-ANSI , den standardiserte versjonen av C- programmeringsspråket , og bruker ikke andre eksterne biblioteker enn standardspråksbiblioteket . Dette gjør SQLite kompileres uten vesentlig modifikasjon på alle datamaskinarkitekturer som gir et C-kompilator i samsvar med ANSI-standarden.

SQLite-databasefiler er helt uavhengige av operativsystemet og arkitekturen de brukes på. Den samme databasefilen kan brukes på to arkitekturer som har radikalt forskjellig drift, og SQLite gir et gjennomsiktig abstraksjonslag for utvikleren. Filene er kompatible med hverandre for hver hovedversjon av biblioteket siden versjon 3.0.0 av SQLite, så en fil opprettet med versjon 3.0.0 vil være brukbar med versjon 3.6.19 og omvendt, filer opprettet mellom to forskjellige hovedversjoner ( 2.0.0 og 3.0.0 for eksempel) kan være kompatible (spesielt bakoverkompatibilitet), men dette er ikke alltid tilfelle.

Datatyper

SQLite bruker dynamisk skriving for celleinnhold, i motsetning til nesten alle DBMS som bruker statisk skriving : når du lager en ny tabell i databasen, er det en anbefalt eller affinitetstype, ikke tvunget, av dataene som skal lagres i kolonnen som er fylt ut og ikke en type som definerer måten dette vil bli representert i minnet, denne oppgaven er reservert for selve cellen. Når data blir lagt inn i databasen, vil SQLite prøve å konvertere de nye dataene til anbefalt type, men vil ikke gjøre det hvis dette ikke er mulig.

Det er flere typer tilknytning i SQLite, disse definerer hvordan SQLite vil fungere når du skriver inn nye data:

TEKST : lagrer dataene som en tegnstreng uten størrelsesbegrensning. Hvis et tall er angitt i en kolonne av denne typen, blir det automatisk konvertert til en tegnstreng;
NUMERIKK : prøver å registrere dataene som et heltall eller som et reelt , men hvis dette viser seg umulig, blir dataene registrert som en tegnstreng;
INTEGER : lagrer dataene som et heltall hvis de kan kodes uten tap, men kan bruke REAL- eller TEXT- typene hvis dette ikke kan gjøres;
REAL : registrerer dataene som et reelt, selv om det er et helt tall. Hvis verdien er for stor, blir dataene konvertert til en tegnstreng.
INGEN : dataene blir registrert som de er, uten konvertering.

Dermed kan hver affinitetstype akseptere hvilken som helst type data, det eneste unntaket er den spesifikke typen INTEGER PRIMARY KEY , når den brukes på en enkelt kolonne, fordi den ikke er en vanlig type, men fra et alias til den interne kolonnen til den ROWID- motor som tilsvarer adressen til posten, unik over bordet.

Bruken av dynamisk skriving forbedrer homogeniteten mellom dataene i databasen og typene språket som brukes til å spørre om det sistnevnte også er et dynamisk skrevet språk (som Python , PHP , Perl eller Ruby ) uten å utgjøre noen reelle problemer med språk ved bruk av statisk skriving (som C / C ++ eller Java ).

Bestemmelse av typen affinitet

For å opprettholde kompatibilitet med andre relasjonsdatabaser konverterer SQLite automatisk navnene på typene som er erklært til den best samsvarende affinitetstypen, slik:

alle typenavn som inneholder INT- nøkkelordet blir gjenkjent som INTEGER- felt . Imidlertid vil bare INTEGER PRIMARY KEY- setningen bli anerkjent som et alias for ROWID ;
alle typenavn som inneholder ett av følgende nøkkelord: CHAR (dette inkluderer VARCHAR ), CLOB eller TEXT vil bli gjenkjent som TEXT- felt ;
alle typenavn som inneholder BLOB- nøkkelordet blir gjenkjent som felt med INGEN tilknytning ;
alle typenavn som inneholder ett av følgende nøkkelord: REAL , FLOAT eller DOUBLE blir gjenkjent som REAL felt ;
i alle andre tilfeller, eller hvis typen ikke er spesifisert, vil NUMERISK affinitet bli brukt.

Selv om SQLite bruker dynamisk skriving, krever representasjonen i minnet og behandlingen som utføres på dataene bruk av forskjellige lagringsklasser. Dette er bare gyldig for versjon 3 og dens senere versjoner, ettersom data ble lagret som strenger i tidligere versjoner.

Alle data som manipuleres av databasemotoren bruker en av følgende typer:

NULL : dataene tilsvarer den spesielle typen NULL , som indikerer fravær av informasjon eller en udefinert verdi;
INTEGER : dataene er et signert heltall, og dette registreres i henhold til størrelsesorden på 1, 2, 3, 4, 6 eller 8 byte , men i minnet blir det konvertert til 8 byte (8 byte signert heltall);
REAL : dataene er et flytende nummer registrert på 8 byte i henhold til IEEE-standarden ;
TEKST : dataene er en tegnstreng, kodet i UTF-8 (standard), UTF-16-BE eller UTF-16-LE ;
BLOB : dataene blir registrert slik de ble gitt.

NULL type

Standarden definerer ikke nøyaktig hvordan NULL- typen skal behandles .

Som med de fleste relasjonsdatabaser, anses alle NULL- poster å være forskjellige av UNIQUE- begrensningen, men anses som identiske av UNION- operatøren og DISTINCT-nøkkelordet .

Aritmetiske operasjoner som inkluderer en NULL- type i uttrykket, returnerer Ukjent (udefinert verdi). I boolske operasjoner kan returverdien være Ukjent hvis en NULL- type forekommer og resultatet ikke kan bestemmes med sikkerhet: NULL ELLER 1 vil gi verdien 1 , men NULL ELLER 0 vil gi verdien Ukjent fordi operasjonen ikke kan løses med sikkerhet .

Datoer

SQLite har ikke en type som representerer datoer. Imidlertid finnes det et sett med funksjoner for å manipulere disse. Lagring av en dato kan gjøres i en tegnstreng i ISO 8601- form eller i et helt tall i form av et UNIX-tidsstempel .

Begrensninger

SQLite administrerer begrensningene for en eller flere kolonner. IKKE NULL , CHECK , DEFAULT og COLLATE begrensninger blir deklarert i kolonnen, mens begrensningene PRIMÆRE NØKKEL , UNIKE , CHECK og UTENLANDSKE NØKKEL kan deklareres i en eller flere kolonner.

UNIQUE- begrensningen oppretter automatisk en indeks på kolonnen / kolonnene den brukes på.

PRIMÆRNØKKEL

Den primære nøkkelbegrensningen vil opprette en UNIQUE begrensning på de berørte kolonnene, men i motsetning til standarden tillater SQLites PRIMÆRE NØKKEL- begrensning oppføringer som er NULL . Dette er en manglende overholdelse av standarden, og dette avviket kan løses i fremtidige versjoner. Det tilrådes derfor å legge til NOT NULL- begrensningen i erklæringen om en primærnøkkel.

ROWID og AUTOINCREMENT

Hver rad i en tabell er identifisert av et 64-bits signert heltall kalt ROWID . Når en tabell er deklarert med en og én INTEGER PRIMÆR NØKKEL- kolonne, blir denne kolonnen et alias for ROWID . Å bruke et alias med ROWID- identifikatoren øker hastigheten på søk, som kan være opptil dobbelt så rask som med en normal primærnøkkel assosiert med dens unike indeks.

Når tabellen er tom, tildeler algoritmen verdien 1 til identifikatoren, som den øker for hver nye post, til den når grensen for et 64-bits signert heltall ( ). Når denne grensen er nådd, vil den gjenbruke mellomrommene frigjort av de slettede postene. Tildelingen av identifikatorer er derfor ikke lenger inkrementell, men tilfeldig. $2 ^ {63} - 1 = 9223372036854775807$

Det er mulig å bruke nøkkelordet AUTOINCREMENT . Sistnevnte endrer algoritmen litt: når grensen for et heltall er nådd, vil det ikke lenger være mulig å sette inn en ny post. Dette gjør det mulig å garantere at samme identifikator aldri blir båret av to forskjellige poster, selv om de ikke eksisterer samtidig.

UTENLANDSK NØKKEL

Siden versjon 3.6.19 er SQLite i stand til å håndtere begrensninger for utenlandske nøkler .

Av bakoverkompatibilitetsårsaker er ikke støtte for utenlandsk nøkkel aktivert som standard. Aktivering er gjort av foreign_keys pragma .

Enhver kolonne det henvises til med en fremmed nøkkel, må erklæres som UNIK ( PRIMÆR NØKKEL oppretter en unik nøkkel). SQLite tar ennå ikke hensyn til MATCH- setningen i definisjonen av utenlandske nøkler.

Utløsere

SQLite administrerer utløsere på en ganske komplett måte. Utløsere FØR , ETTER eller INSTEAD AV kan rapporteres. SQLite støtter alternativet FOR HVER RAD (standardoperasjon), men ikke FOR HVER ERKLÆRING .

Visninger

SQLite tillater oppretting av visninger for å redusere lengden på spørringene.

Visninger er skrivebeskyttet, men det er mulig å bruke utløsere med egenskapen INSTEAD OF for å simulere muligheten til å endre dem.

Transaksjoner

Alle SQL-kommandoer som tar sikte på å endre tilstanden til databasen (stort sett alle andre kommandoer enn SELECT ) innebærer oppretting av en transaksjon dedikert til dem, så lenge en transaksjon som inkluderer kommandoen ikke allerede er opprettet. Dette betyr at alle kommandoene er atomare . Hvis utførelsen av kommandoen ikke forårsaker en feil, blir modifikasjonen automatisk begått ( autocommit ), men hvis dette ikke er tilfelle, blir alle endringene som er gjort av kommandoen kansellert.

Alle modifikasjoner i databasen serialiseres: bare én endring utføres om gangen, og databasen er låst for lesing under en modifisering.

SQLite tillater oppretting av transaksjoner så vel som opprettelse av returpunkter ( SAVEPOINT ), men tillater ikke å håndtere forskjellige grader av isolasjon. I en transaksjon, under det første anropet til en lese-kommando, aktiveres en delt lås som autoriserer lesetilgang, men som ikke tillater endring av dataene ved en annen transaksjon, under den første skriveanropet blir hele databasen lest og skrevet låst for andre transaksjoner .

SYRE

Selv om SQLite ved første øyekast respekterer settet med ACID-egenskaper , som bestemmer påliteligheten til et transaksjonssystem, er det fortsatt mulig å sette databasen i en inkonsekvent tilstand fordi typene ikke er tvunget: det er for eksempel mulig å sette inn en tegnstreng i en kolonne hvis tilhørighetstype er definert som et heltall . I sine strenge tolkninger respekterer ikke SQLite settet med ACID-egenskaper.

Midlertidige bord

SQLite tillater oppretting av midlertidige tabeller hvis definisjon, data og indekser ikke er lagret i databasefilen og derfor går tapt når databasen lukkes.

Virtuelle tabeller

Det er mulig å lage sin egen lagringsmotor direkte fra biblioteket for å simulere en databasetabell. Opprettelsen av et virtuelt bord gjøres ved å implementere et sett med funksjoner. Tilgang til tabellen er helt gjennomsiktig, bortsett fra fraværet av visse funksjoner (umulig å lage utløsere eller indekser eller å endre strukturen på tabellen).

Denne mekanismen gir tilgang til SQL-språk til alle slags datakilder, for eksempel CSV- eller XML- filer .

Brukerfunksjoner

SQLite tilbyr et programmeringsgrensesnitt, gjennom biblioteket, for å opprette brukerfunksjoner . Funksjonssettene som er definert av biblioteket kan overbelastes for å omdefinere implementeringen av dem. Noen operatører, som LIKE, bruker eponyme funksjoner som et underlag, som også kan erstattes av brukerdefinerte funksjoner.

SQLite støtter ikke oppretting av prosedyrer , men deres behov er mindre på grunn av den innebygde arkitekturen.

Indeks

SQLite tillater oppretting av indekser på en eller flere kolonner. Indekser kan være stigende ( ASC ) eller synkende ( DESC ) så vel som unike (dette ligner på å skape en unik begrensning). SQLite bruker sin indeks B-treet .

SQLite introduserer nøkkelordet EXPLAIN som brukes til å beskrive trinnene som kreves for å utføre en kommando, samt indeksene som brukes.

Pragmas

Pragmas er SQLite-konfigurasjonsnøkkel / verdipar. De er interne i en database og lar deg beskrive hvordan SQLite skal tolke visse operasjoner. De lar deg også aktivere eller deaktivere visse funksjoner, spesielt av bakoverkompatibilitetsårsaker.

Adopsjon

Foruten den offisielle implementeringen i C , finnes det bindinger for andre språk ( C ++ , Perl , Ruby , TCL , språk som bruker .NET-rammeverket via en ADO.NET- driver ...).

Noen programmeringsspråk inkluderer SQLite i standardbiblioteket , for eksempel Python (siden versjon 2.5) og PHP (siden versjon 5).

SQLite brukes i mange gratis programvare, som Mozilla Firefox , i mange GNU / Linux- distribusjoner , i server- og stasjonære operativsystemer som Solaris eller mobile som Android eller Symbian , i noe programvare fra Apple , Google , Adobe og McAfee samt noen enheter Philips .

SQLite er også tilgjengelig med versjon 8.4 av Primavera P6-programvaren fra Oracle.

Utkastet til lagring av en SQL-database på nettlesersiden publisert av W3C sier også at programvare som implementerer denne funksjonen, må kunne tolke dialekten til SQLite riktig i sin versjon 3.6.19 . Selv om SQLite ikke håndheves av W3C, bruker Google Chrome , Apple Safari og Opera Browser det til dette formålet.

Ulike versjoner

SQLite finnes i to hovedversjoner: 2.x og 3.x. SQLite versjoner 2 og 3 preges av flere evolusjoner:

databasefiler er ikke alltid kompatible med hverandre. Dette betyr at en database i SQLite 2-format ikke kan leses med sikkerhet av SQLite 3 og omvendt ;
SQL-syntakser er ikke tilstede i SQLite 2: HVIS IKKE eksisterer for spørsmål, og CREATE TABLE , ADD COLUMN og RENAME COLUMN for ALTER TABLE- spørsmål ;
bare de nyeste versjonene av SQLite støtter visse mer avanserte funksjoner, for eksempel administrasjon av utenlandsk nøkkel eller CHECK- begrensninger ;
SQLite 3 støtter UTF-8 og UTF-16 standarder ;
SQLite 3 koder radidentifikatorene på 64 bits og ikke lenger på 32 bits , noe som gir et nesten ubegrenset antall rader;
PHP bruker en PDO- klasse eller, med PHP 5.3, sqlite3 _ * () -funksjoner for å håndtere SQLite 3 mens den bruker sqlite _ * () -funksjoner for SQLite 2.

Merknader og referanser

" SQLite utgivelse 3.36.0 2021-06-18 " (åpnet 18. juni 2021 )
" SQLite Copyright " , på www.sqlite.org
“ Om SQLite ” , på www.sqlite.org
“ Kjente brukere av SQLite ” , på www.sqlite.org
“ Most Deployed SQL Database Engine ” , på www.sqlite.org
(in) Michael Owens , The Definitive Guide to SQLite , Berkeley, Apress,2006( ISBN 978-1-59059-673-9 , DOI 10.1007 / 978-1-4302-0172-4_1 )
“ The SQLite Bytecode Engine ” , på www.sqlite.org
" Virtual Database Engine of SQLite " , på www.sqlite.org
“ Architecture of SQLite ” , på www.sqlite.org
" SQL-funksjoner som SQLite ikke implementerer " , på www.sqlite.org
“ Nullkonfigurasjon ” , på www.sqlite.org
“ SQLite er et selvforsynt system ” , på www.sqlite.org
" SQLite: Single File Database " , på www.sqlite.org
" Datatyper i SQLite versjon 3 " , på www.sqlite.org
" SQLite Query Language: CREATE TABLE " , på www.sqlite.org
“ Oversikt over SQLite versjon 3 ” , på www.sqlite.org
“ NULL Handling in SQLite ” , på www.sqlite.org
" SQLite Query Language: Date And Time Functions " , på www.sqlite.org
“ Syntaksdiagrammer for SQLite ” , på www.sqlite.org
“ SQLite Autoincrement ” , på www.sqlite.org
“ SQLite Foreign Key Support ” , på www.sqlite.org
" SQLite Query Language: CREATE TRIGGER " , på www.sqlite.org
" SQLite Query Language: CREATE VIEW " , på www.sqlite.org
" SQLite Query Language: SAVEPOINT " , på www.sqlite.org
" Fillåsing og samtidighet i SQLite versjon 3 " , på www.sqlite.org
" SQLite Query Language: BEGIN TRANSACTION " , på www.sqlite.org
" Virtual Table Mechanism Of SQLite " , på www.sqlite.org
“ SQLite Query Language: Core Functions ” , på www.sqlite.org
" SQLite Query Language: CREATE INDEX " , på www.sqlite.org
" SQLite Query Language: EXPLAIN " , på www.sqlite.org
“ Pragma-utsagn støttet av SQLite ” , på www.sqlite.org
http://sqlite.phxsoftware.com/
" sqlite3 - DB-API 2.0-grensesnitt for SQLite databaser - Python 3.7.3 dokumentasjon " , på docs.python.org
" PHP: Hypertext Preprocessor " , på www.php.net
“ Web SQL Database ” på dev.w3.org
" Flere ressurser for utviklere "
" WebKit HTML 5 SQL Storage Notes Demo " , på webkit.org
“ Dev.Opera - Blog ” , på dev.opera.com

Eksterne linker

Offisiell side
( fr ) SQLite Consortium , Mitchell Baker, 27. februar 2008.
SQLite blir standarddatabasen til det frakoblede nettet , David Maume, 01net,29. februar 2008.