SQLite

Information

Udviklet af	D. Richard Hipp
Første version	August 2000
Sidste version	3.36,0 (18. juni 2021)
Depositum	www.sqlite.org/src
Skrevet i	VS
Operativ system	Multiplatform
Læs formater	SQLite-databasefilformat ( d ) , SQLite 3.x-database ( d ) og SQLite rollbak-journal ( d )
Skriftlige formater	SQLite-databasefilformat ( d ) , SQLite 3.x-database ( d ) , SQLite Zipvfs komprimeret database ( d ) og SQLite rollbak-journal ( d )
Type	Indbygget databasestyringssystem ( d )
Licens	Offentligt domæne
Internet side	sqlite.org

SQLite (udtalt [ ɛs.ky.ɛl.ajt ]) er et bibliotek skrevet på sprog C, der tilbyder motor af relationel database tilgængelig sprog SQL . SQLite implementerer stort set SQL-92 standard-og ACID-egenskaberne .

I modsætning til traditionelle database -servere , såsom MySQL eller PostgreSQL , dets særegenhed er ikke at gengive den sædvanlige klient-server -ordningen , men at være direkte integreret i programmerne . Hele databasen (erklæringer, tabeller, indeks og data) er gemt i en fil uafhængig af platformen .

D. Richard Hipp , skaberen af SQLite, har valgt at placere dette bibliotek og dets kildekode i det offentlige domæne , hvilket tillader dets ubegrænsede brug i både open source og proprietære projekter . Skaberen og nogle af de vigtigste udviklere af SQLite er ansat i det amerikanske firma Hwaci .

SQLite er den mest anvendte databasemotor i verden takket være brugen:

i mange forbruger -software såsom Firefox , Skype , Google Gears ,
i visse produkter fra Apple , Adobe og McAfee ,
i de almindelige biblioteker i mange sprog som PHP eller Python .

På grund af sin ekstreme lethed (mindre end 600 KiB ) er det også meget populært på indlejrede systemer , især på de fleste moderne smartphones og tablets : iOS , Android og Symbian mobile operativsystemer bruger det som en database. I alt kan vi tælle mere end en milliard kendte og rapporterede kopier af biblioteket.

Historisk

D. Richard Hipp og en kollega begyndte at designe SQLite i begyndelsen af 2000, mens de arbejdede hos General Dynamics , derefter under kontrakt med den amerikanske flåde . SQLite skulle bruges i styrede missiler for at erstatte IBM Informix- databaser, der kørte på HP-UX- maskiner . Hovedformålet var at kunne klare sig uden installation eller administration: installationen eller opdateringen af databasen kunne tage en hel dag.

I august 2000 blev den første version af SQLite frigivet. Hun brugte gdbm ( GNU Database Manager) til at manipulere B-træer .

SQLite 2.0 fjerner afhængigheden af gdbm og tilføjer transaktionssupport.

SQLite 3.0, produceret ved hjælp af AOL , blev udgivet i 2004 og tilføjer blandt andet regionalisering (med sortering og Unicode-support ) og typedeklaration.

Egenskaber

Indbygget database

Hovedparten af database management systemer er bygget efter den klient-server paradigme , det vil sige en klient -software bibliotek er integreret og anvendt i et eller flere programmer, mens databasen motoren kører. I sin egen henrettelse plads, eller endda på en anden maskine, som IT-afdeling .

Tværtimod er SQLite direkte integreret i applikationen, der bruger softwarebiblioteket med databasemotoren. Adgang til en database med SQLite sker ved at åbne den fil, der svarer til den: hver database gemmes i en fil, der er specifik for den med dens erklæringer, dens tabeller og dens indekser, men også dens data.

Denne egenskab gør SQLite interessant som et alternativ til tekstfiler, der bruges som et middel til integreret lagring i mange applikationer ( parametre , historie , cache ...), fordi det gør adgang til data hurtigere, mere sikker, mere struktureret, lettere og fuldstændig uafhængig af platformen , mens det ikke påvirker den lette installation af den applikation, der bruger den.

Fjernelse af mellemmanden mellem applikation og data reducerer også datatilgangsforsinkelsen lidt sammenlignet med systemer, der bruger klientserverparadigmet.

Denne arkitektur udgør dog flere problemer:

når et stort antal klienter får adgang til den samme database, hvis en af klienterne begynder at læse en del, er hele databasen låst skriftligt for de andre klienter, og omvendt, hvis en af klienterne begynder at skrive til del, er hele databasen blokeret til læsning for andre klienter. Sidstnævnte sættes derefter på hold i løbet af denne tidsperiode, hvilket kan være modeffektivt;
det er meget kompliceret at distribuere belastningen på flere maskiner: brugen af et filsystem på netværket genererer ventetid og betydelig trafik, fordi basen skal genindlæses hos kunden hver gang den åbnes. Dette problem er endnu vigtigere med websteder, hvor databasen genåbnes for hver anmodet side. Derudover kan der opstå fejl i synkroniseringen af fillåse, som kan muliggøre samtidig skrivning til to forskellige klienter på den samme del af databasen og dermed føre til databasekorruption;
med store databaser er det ikke muligt at opdele databasen i flere dele eller filer for at distribuere belastningen på flere maskiner. Nogle filsystemer, som FAT 32 , har en maksimal filstørrelse, der hurtigt kan begrænse udvidelsen af en database.

Der er ingen specifik udvidelse til SQLite-databasefiler, men det er almindeligt at støde på udvidelser som .sqlite eller .db , undertiden efterfulgt af biblioteksversionsnummeret ( .sqlite3 , .db2 osv.). Det er muligt at anvende en database kun gemt i RAM uden at skabe database fil på disken, via det særlige filnavn : hukommelse: .

Generelt anbefales det at bruge SQLite, hvor dataene ikke er centraliseret, og hvor udvidelsen af databasens størrelse sandsynligvis ikke bliver kritisk. Hvis formålet med databasen er at centralisere en stor datamængde og levere dem til et stort antal klienter, foretrækkes det at bruge DBMS'er baseret på klient-serverparadigmet. SQLite er beregnet til at erstatte tekstfiler, ikke traditionelle databaseservere.

Compiler og virtuel maskine

Når en SQL-forespørgsel sendes til SQLite gennem programmeringsgrænsefladen , kompileres den, før den udføres.

Compilerens sequencer opdeler de kommandoer, der er givet i dele, der kan behandles separat (f.eks. En forespørgsel og dens underforespørgsel), som sendes til parseren, som sørger for at nedbryde forespørgslerne i forskellige objekter, der repræsenterer de forskellige ordrer. klausuler om SQL-sproget. Disse objekter sendes til kodegeneratoren, der opretter en mellemkode på lavt niveau eller bytekode .

Den resulterende kode er et sæt instruktioner (137 forskellige instruktioner) kaldet OpCodes . Dette lanceres i SQLites virtuelle maskine, der ser dem som små programmer, der beskriver datasøgning, læsning og ændring.

Når den virtuelle maskine fortolker disse instruktioner, hun kaldte manager for B-træ baseret på lag lavere niveau, som skjuler den sider disken og hardware abstraktionslag .

Rettighedsstyring

SQLite integrerer ikke styring af adgangsrettigheder og datamodifikation. Ledelsen er udført af filsystemet af operativsystemet : hvis den fil, der indeholder databasen ikke skrive til en bruger, vil brugeren også være i stand til at ændre de optegnelser og den grundlæggende struktur af data.

Rettighedsstyring med GRANT og REVOKE findes derfor ikke, selvom disse er en del af SQL-92- specifikationen .

Brug af en SQLite-database kræver ingen installations- eller konfigurationsprocedure.

Bærbarhed

Biblioteket er udelukkende skrevet i C-ANSI , den standardiserede version af C- programmeringssproget , og bruger ikke andre eksterne biblioteker end standardsprogbiblioteket . Dette gør SQLite kompilérbar uden større ændringer på alle computerarkitekturer, der leverer en C-compiler, der overholder ANSI-standarden.

SQLite-databasefiler er helt uafhængige af operativsystemet og den arkitektur, de bruges på. Den samme databasefil kan bruges på to arkitekturer, der har radikalt forskellige operationer, og SQLite giver et gennemsigtigt abstraktionslag til udvikleren. Filerne er kompatible med hinanden for hver større version af biblioteket siden version 3.0.0 af SQLite, så en fil oprettet med version 3.0.0 kan bruges med version 3.6.19 og omvendt, filer oprettet mellem to forskellige større versioner ( 2.0.0 og 3.0.0 for eksempel) kan være kompatible (især bagudkompatibilitet), men dette er ikke altid tilfældet.

Datatyper

SQLite bruger dynamisk skrivning til celleindhold, i modsætning til næsten alle DBMS, der bruger statisk skrivning : Når der oprettes en ny tabel i databasen, er det en anbefalet eller affinitetstype, ikke tvunget, af de data, der skal gemmes i kolonnen, der udfyldes og ikke en type, der definerer den måde, hvorpå dette vil blive repræsenteret i hukommelsen, hvor denne opgave er forbeholdt selve cellen. Når data indtastes i databasen, vil SQLite forsøge at konvertere de nye data til den anbefalede type, men vil ikke gøre det, hvis dette ikke er muligt.

Der er flere typer affinitet i SQLite, disse definerer, hvordan SQLite fungerer, når man indtaster nye data:

TEKST : gemmer dataene som en tegnstreng uden størrelsesbegrænsning. Hvis et tal indtastes i en kolonne af denne type, konverteres det automatisk til en tegnstreng;
NUMERISK : forsøger at registrere dataene som et heltal eller som en reel , men hvis dette viser sig umuligt, registreres dataene som en tegnstreng;
INTEGER : gemmer dataene som et heltal, hvis de kan kodes uden tab, men kan bruge REAL- eller TEXT- typerne, hvis dette ikke kan gøres;
REAL : registrerer dataene som en reel, selvom det er et heltal. Hvis værdien er for stor, konverteres dataene til en tegnstreng;
INGEN : dataene registreres som de er uden konvertering.

Således kan hver affinitetstype acceptere enhver type data, den eneste undtagelse er den bestemte type INTEGER PRIMÆR NØGLE , når den anvendes på en enkelt kolonne, fordi den ikke er en almindelig type. Men fra et alias til den interne kolonne til den ROWID- motor, der svarer til postens adresse, unik over bordet.

Brugen af dynamisk skrivning forbedrer homogeniteten mellem dataene i databasen og typerne af det sprog, der bruges til at forespørge, hvis sidstnævnte også er et dynamisk skrevet sprog (såsom Python , PHP , Perl eller Ruby ) uden at udgøre nogen reelle problemer med sprog ved hjælp af statisk typing (som C / C ++ eller Java ).

Bestemmelse af typen af affinitet

For at opretholde kompatibilitet med andre relationsdatabaser konverterer SQLite automatisk navnene på de typer, der er erklæret til den bedst matchende affinitetstype, som følger:

alle typenavne, der indeholder INT- nøgleordet , genkendes som INTEGER- felter . Imidlertid vil kun INTEGER PRIMARY KEY- erklæringen blive anerkendt som et alias for ROWID ;
alle typebetegnelser, der indeholder et af følgende nøgleord: CHAR (dette inkluderer VARCHAR ), CLOB eller TEXT genkendes som TEXT- felter ;
alle typenavne, der indeholder BLOB- nøgleordet , genkendes som felter med INGEN affinitet ;
alle typebetegnelser, der indeholder et af følgende nøgleord: REAL , FLOAT eller DOUBLE genkendes som REAL felter ;
i alle andre tilfælde, eller hvis typen ikke er specificeret, vil den NUMERISKE affinitet blive brugt.

Selvom SQLite bruger dynamisk skrivning, kræver in-memory-repræsentationen og behandlingen, der udføres på dataene, brug af forskellige lagerklasser. Dette gælder kun for version 3 og dens senere versioner, da data blev gemt som strenge i tidligere versioner.

Alle data manipuleret af databasemotoren bruger en af følgende typer:

NULL : dataene svarer til den specielle type NULL , som indikerer fravær af information eller en udefineret værdi;
INTEGER : dataene er et signeret heltal, og dette registreres i henhold til dets størrelsesorden på 1, 2, 3, 4, 6 eller 8 byte , men i hukommelsen konverteres det til 8 byte (8 byte underskrevet heltal);
VIRKELIG : dataene er et flydende nummer registreret 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 registreres som de blev givet.

NULL- type

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

Som med de fleste relationsdatabaser betragtes alle NULL- poster som forskellige af UNIQUE- begrænsningen, men betragtes som identiske af UNION- operatøren og DISTINCT-nøgleordet .

Aritmetiske operationer, der inkluderer en NULL- type i deres udtryk, returnerer Ukendt (udefineret værdi). I boolske operationer kan returværdien være Ukendt, hvis en NULL- type opstår, og resultatet ikke kan bestemmes med sikkerhed: NULL ELLER 1 giver værdien 1 , men NULL ELLER 0 giver værdien Ukendt, fordi operationen ikke kan løses med sikkerhed .

Datoer

SQLite har ikke en type, der repræsenterer datoer. Der findes dog et sæt funktioner til at manipulere disse. Lagring af en dato kan ske i en tegnstreng i sin ISO 8601- form eller i et heltal i form af et UNIX-tidsstempel .

Begrænsninger

SQLite administrerer begrænsningerne for en eller flere kolonner. Begrænsningerne IKKE NULL , CHECK , DEFAULT og COLLATE erklæres i kolonnen, mens begrænsningerne PRIMÆR NØGLE , UNIK , CHECK og UDENLANDSK KEY kan deklareres i en eller flere kolonner.

UNIQUE- begrænsningen opretter automatisk et indeks på den eller de kolonner, som det anvendes på.

PRIMÆRNØGLE

Den primære nøglebegrænsning opretter en UNIQUE- begrænsning på de berørte søjler, men i modsætning til standarden tillader SQLites PRIMÆRE NØGLE- begrænsning poster, der er NULL . Dette er en manglende overholdelse af standarden, og denne afvigelse kan løses i fremtidige versioner. Det tilrådes derfor at tilføje IKKE NULL- begrænsningen til erklæringen om en primær nøgle.

ROWID og AUTOINCREMENT

Hver række i en tabel identificeres med et 64-bit underskrevet heltal kaldet ROWID . Når en tabel erklæres med én og kun en INTEGER PRIMÆR NØGLE- kolonne, bliver denne kolonne et alias for ROWID . Brug af et alias med ROWID- identifikatoren øger søgningshastigheden , som kan være op til dobbelt så hurtig som med en normal primærnøgle, der er knyttet til dens unikke indeks.

Når tabellen er tom, tildeler algoritmen værdien 1 til identifikatoren, som den forøger for hver ny post, indtil den når grænsen for et 64-bit underskrevet heltal ( ). Når denne grænse er nået, vil den genbruge de pladser, der frigøres af de slettede poster. Tildelingen af identifikatorer er derfor ikke længere inkrementel, men tilfældig. $2 ^ {63} - 1 = 9223372036854775807$

Det er muligt at bruge nøgleordet AUTOINCREMENT . Sidstnævnte ændrer algoritmen lidt: når grænsen for et heltal er nået, er det ikke længere muligt at indsætte en ny post. Dette gør det muligt at garantere, at den samme identifikator aldrig bæres af to forskellige optegnelser, selvom de ikke eksisterer samtidig.

FREMMED NØGLE

Siden version 3.6.19 er SQLite i stand til at styre udenlandske nøglebegrænsninger .

Af baglæns kompatibilitetsårsager er understøttelse af fremmed nøgler ikke aktiveret som standard. Aktivering udføres af fremmed- nøglen pragma .

Enhver kolonne, der henvises til med en fremmed nøgle, skal erklæres som UNIK ( PRIMÆR NØGLE opretter en unik nøgle). SQLite tager endnu ikke højde for MATCH- klausulen i definitionen af fremmednøgler.

Udløsere

SQLite administrerer udløsere på en ret komplet måde. Udløsere FØR , EFTER eller INSTEAD AF kan rapporteres. SQLite understøtter indstillingen FOR EACH ROW (standardhandling), men ikke FOR EACH STATEMENT .

Visninger

SQLite tillader oprettelse af visninger for at reducere længden af forespørgsler.

Visninger er skrivebeskyttet, men det er muligt at bruge udløsere med egenskaben INSTEAD OF til at simulere muligheden for at ændre dem.

Transaktioner

Alle SQL-kommandoer, der sigter mod at ændre databasens tilstand (stort set enhver anden kommando end SELECT ), involverer oprettelse af en transaktion dedikeret til dem, så længe en transaktion, der inkluderer kommandoen, ikke allerede er oprettet. Dette betyder, at alle kommandoer er atomare . Hvis udførelsen af kommandoen ikke forårsager en fejl, foretages ændringen automatisk ( autocommit ), men hvis dette ikke er tilfældet, annulleres alle ændringer foretaget af kommandoen.

Alle ændringer til databasen er seriel: kun en ændring udføres ad gangen, og databasen er låst til læsning under en ændring.

SQLite tillader oprettelse af transaktioner såvel som oprettelse af returpunkter ( SAVEPOINT ), men tillader ikke styring af forskellige grader af isolation. I en transaktion aktiveres en delt lås under det første opkald til en læsekommando, som autoriserer læseadgang, men forbyder enhver modifikation af dataene ved en anden transaktion, under det første skriveopkald læses hele databasen og skrivelåsen til andre transaktioner .

SYRE

Selvom SQLite ved første øjekast respekterer sættet med ACID-egenskaber , som bestemmer pålideligheden af et transaktionssystem, er det stadig muligt at sætte databasen i en inkonsekvent tilstand, fordi typerne ikke er tvunget: det er f.eks. Muligt at indsætte en tegnstreng i en kolonne, hvis affinitetstype er defineret som et heltal . I deres strenge fortolkninger respekterer SQLite ikke sæt ACID-egenskaber.

Midlertidige borde

SQLite tillader oprettelse af midlertidige tabeller, hvis definition, data og indekser ikke er gemt i databasefilen og derfor går tabt, når databasen lukkes.

Virtuelle tabeller

Det er muligt at oprette, direkte fra biblioteket, sin egen lagermotor for at simulere en databasetabel. Oprettelsen af en virtuel tabel sker ved at implementere et sæt funktioner. Adgang til tabellen er fuldstændig gennemsigtig bortset fra fraværet af visse funktionaliteter (umuligt at oprette udløsere eller indekser eller ændre strukturens struktur).

Denne mekanisme giver adgang ved hjælp af SQL-sprog til enhver form for datakilde, såsom CSV- eller XML- filer .

Brugerfunktioner

SQLite tilbyder en programmeringsgrænseflade gennem sin bibliotek, for at skabe brugergrupper funktioner . Sættet af funktioner, der er defineret af biblioteket, kan overbelastes for at omdefinere deres implementering. Nogle operatører, som LIKE, bruger eponyme funktioner som et underlag, som også kan erstattes af brugerdefinerede funktioner.

SQLite understøtter ikke oprettelse af procedurer , men deres behov er mindre på grund af den integrerede arkitektur.

Indeks

SQLite tillader oprettelse af indekser i en eller flere kolonner. Indekser kan være stigende ( ASC ) eller faldende ( DESC ) såvel som unikke (dette svarer til at skabe en unik begrænsning). SQLite bruger sit indeks B-træ .

SQLite introducerer nøgleordet FORKLAR, som bruges til at beskrive de nødvendige trin for at udføre en kommando samt de anvendte indekser.

Pragmas

Pragmas er SQLite-konfigurationsnøgle / værdipar. De er interne i en database og giver dig mulighed for at beskrive, hvordan SQLite skal fortolke bestemte operationer. De giver dig også mulighed for at aktivere eller deaktivere bestemte funktioner, især af bagudkompatibilitetsårsager.

Adoption

Udover den officielle implementering i C findes der bindinger til andre sprog ( C ++ , Perl , Ruby , TCL , sprog ved hjælp af .NET-rammen via en ADO.NET- driver ...).

Nogle programmeringssprog inkluderer SQLite i deres standardbibliotek , for eksempel Python (siden version 2.5) og PHP (siden version 5).

SQLite bruges i mange gratis software, som Mozilla Firefox , i mange GNU / Linux- distributioner , i server- og desktop- operativsystemer som Solaris eller mobile som Android eller Symbian , i noget software fra Apple , Google , Adobe og McAfee samt nogle enheder Philips .

SQLite er også tilgængelig med version 8.4 af Primavera P6-softwaren fra Oracle.

Udkastet til lagring af en SQL-database på webbrowsersiden offentliggjort af W3C siger også, at software, der implementerer denne funktion, skal kunne fortolke dialekten af SQLite korrekt i sin version 3.6.19 . Selvom SQLite ikke håndhæves af W3C, bruger Google Chrome , Apple Safari og Opera Browser det til dette formål.

Forskellige versioner

SQLite findes i 2 hovedversioner: 2.x og 3.x. SQLite version 2 og 3 er kendetegnet ved flere udviklinger:

databasefiler er ikke altid kompatible med hinanden. Dette betyder, at en database i SQLite 2-format ikke kan læses med sikkerhed af SQLite 3 og omvendt ;
SQL-syntakser er ikke til stede i SQLite 2: HVIS IKKE FINDER for forespørgsler, og Opret TABEL , TILFØJ KOLONNE og RENAME COLUMN til ALTER TABLE- forespørgsler ;
kun de nyeste versioner af SQLite understøtter visse mere avancerede funktioner, såsom udenlandsk nøglehåndtering eller CHECK- begrænsninger ;
SQLite 3 understøtter UTF-8 og UTF-16 standarder ;
SQLite 3 koder rækkeidentifikatorerne på 64 bit og ikke længere på 32 bit , hvilket tillader et næsten ubegrænset antal rækker;
PHP bruger en PDO- klasse eller, med PHP 5.3, sqlite3 _ * () -funktioner til at håndtere SQLite 3, mens den bruger sqlite _ * () -funktioner til SQLite 2.

Noter og referencer

" SQLite-frigivelse 3.36.0 den 2021-06-18 " (adgang til 18. juni 2021 )
" SQLite Copyright " , på www.sqlite.org
“ Om SQLite ” på www.sqlite.org
“ Kendte brugere af SQLite ” på www.sqlite.org
“ Mest udbredt SQL Database Engine ” på www.sqlite.org
(i) Michael Owens , den definitive guide til SQLite , Berkeley, Apress,2006( ISBN 978-1-59059-673-9 , DOI 10.1007 / 978-1-4302-0172-4_1 )
“ SQLite Bytecode Engine ” på www.sqlite.org
" Virtual Database Engine of SQLite " , på www.sqlite.org
“ Arkitektur af SQLite ” , på www.sqlite.org
" SQL-funktioner, som SQLite ikke implementerer " , på www.sqlite.org
” Nul-konfiguration ” , på www.sqlite.org
“ SQLite er et selvstændigt system ” , på www.sqlite.org
" SQLite: Single File Database " , på www.sqlite.org
" Datatyper i SQLite version 3 " , på www.sqlite.org
" SQLite Query Language: CREATE TABLE " , på www.sqlite.org
“ Oversigt over SQLite version 3 ” på www.sqlite.org
“ NULL Handling in SQLite ” , på www.sqlite.org
" SQLite Query Language: Date and Time Funktions " , på www.sqlite.org
“ Syntaksdiagrammer til 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åsning og samtidighed i SQLite version 3 " , på www.sqlite.org
" SQLite Query Language: BEGIN TRANSACTION " , på www.sqlite.org
" Den virtuelle tabelmekanisme ved 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-sætninger understøttet af SQLite ” , på www.sqlite.org
http://sqlite.phxsoftware.com/
" sqlite3 - DB-API 2.0 interface til SQLite databaser - Python 3.7.3 dokumentation " , på docs.python.org
" PHP: Hypertext Preprocessor " , på www.php.net
“ Web SQL Database ” på dev.w3.org
" Flere ressourcer for udviklere "
" WebKit HTML 5 SQL Storage Notes Demo " , på webkit.org
“ Dev.Opera - Blog ” , på dev.opera.com

eksterne links

Officielt websted
( fr ) SQLite Consortium , Mitchell Baker, 27. februar 2008.
SQLite bliver standarddatabasen for det frakoblede web , David Maume, 01net,29. februar 2008.