Løft panseret på de fleste forretningsapplikasjoner, og du vil avsløre en måte å lagre og bruke strukturerte data på. Enten det er en klientside-app, en app med en web-front-end eller en edge-device-app, er sjansen stor for at den trenger en innebygd database av noe slag.
SQLite er en innebygd åpen kildekodedatabase, skrevet i C og kan spørres med konvensjonell SQL, som er designet for å dekke brukssaker og mer. SQLite er designet for å være rask, bærbar og pålitelig, enten du bare lagrer kilobyte data eller multigigabyte-klatter.
Hvor du kan bruke SQLite
En av SQLites største fordeler er at den kan kjøre nesten hvor som helst. SQLite har blitt portet til et bredt utvalg av plattformer: Windows, MacOS, Linux, iOS, Android og mer. Spesielt Windows-brukere kan bruke forhåndskompilerte binærfiler for vanlige Win32, UWP, WinRT og .Net. Uansett hva distribusjonsmålet er for appen din, er det sannsynlig at det er en versjon av SQLite tilgjengelig for den, eller en måte å portere C-kildekoden til det målet.
Apper som bruker SQLite, trenger ikke å skrives på et bestemt språk, så lenge det er noen måte å binde og arbeide med eksterne biblioteker skrevet i C. SQLites binære filer er selvstendige, så de krever ingen spesiell magi for å distribuere— de kan rett og slett slippes i samme katalog som applikasjonen.
Mange språk har bindinger på høyt nivå for SQLite som bibliotek, og kan bruke det sammen med andre databasetilgangslag for språket. Python, for eksempel, pakker SQLite-biblioteket som et standardutgaveelement med lagerversjonen av Python-tolken. I tillegg har tredjeparter skrevet et bredt utvalg av ORM-er og datalag som bruker SQLite, slik at du ikke har tilgang til SQLite via rå SQL-strenger (som ikke bare er klønete, men også potensielt farlig).
Til slutt er kildekoden for SQLite offentlig domene, så den kan brukes på nytt i andre programmer uten praktiske begrensninger.
SQLite fordeler
Den vanligste og mest åpenbare brukssaken for SQLite er å tjene som en konvensjonell, bordorientert relasjonsdatabase. SQLite støtter transaksjoner og atomatferd, slik at et programkrasj eller til og med et strømbrudd ikke gir deg en ødelagt database.
SQLite har funksjoner som finnes i avanserte databaser som indeksering av fulltekst og støtte for JSON-data. Applikasjonsdata som vanligvis er fylt i semistrukturerte formater som YAML eller XML, kan lagres som SQLite-tabeller, slik at data blir lettere tilgjengelig og behandlet raskere.
SQLite gir også en rask og kraftig måte å lagre konfigurasjonsdata for et program på. I stedet for å analysere et filformat som YAML, kan en utvikler bruke SQLite som et grensesnitt til disse filene - ofte langt raskere enn å bruke dem manuelt. SQLite kan fungere med data i minnet eller eksterne filer (f.eks. CSV-filer) som om de var opprinnelige databasetabeller, noe som gir en praktisk måte å spørre om dataene på.
Fordi SQLite er en enkelt frittstående binær, er det enkelt å distribuere med en app og flytte den med appen etter behov. Hver database opprettet av SQLite består også av en enkelt fil, som kan komprimeres eller optimaliseres ved hjelp av SQL-kommandoer.
Tredjeparts binære utvidelser for SQLite legger til enda mer funksjonalitet. SQLCipher legger til 256-biters AES-kryptering i SQLite-databasefiler. En annen, SQLite-Bloomfilter, lar deg lage blomstringsfiltre fra data i et gitt felt.
Mange andre tredjepartsprosjekter gir ekstra verktøy for SQLite, for eksempel Visual Studio Code-utvidelsen som gjør det mulig å bla gjennom databaser fra Visual Studio Code, eller den interaktive LiteCLI-kommandolinjen for SQLite. En kuratert liste over SQLite-ressurser på GitHub inneholder mange flere.
SQLite vs. MySQL
SQLite sammenlignes oftest med MySQL (eller MariaDB) - det mye brukte databasen med åpen kildekode som er en stift for dagens applikasjonsstabler. Så mye som SQLite kan ligne MySQL, er det mye å skille disse to databasene fra hverandre - og gode grunner til å favorisere hverandre, avhengig av brukssaken.
Datatyper
SQLite har relativt få datatyper — BLOB, NULL, INTEGER og TEXT. MySQL (eller MariaDB), derimot, har dedikerte datatyper for datoer og klokkeslett, forskjellige presisjoner av heltall og flyt, og mye mer.
Hvis du lagrer relativt få datatyper, eller hvis du vil bruke datalaget ditt til å utføre validering av dataene, er SQLite nyttig. Imidlertid, hvis du vil at datalaget ditt skal gi sin egen validering og normalisering, går du med MySQL (eller MariaDB).
Konfigurasjon og innstilling
SQLites konfigurasjons- og innstillingsalternativer er minimale. De fleste interne eller kommandolinjeflagg for SQLite håndterer kantsaker eller bakoverkompatibilitet. Dette passer med SQLites overordnede filosofi om enkelhet: Gjør standardalternativene velegnet til de vanligste brukssakene.
MySQL (eller MariaDB) har en ekte skog med database- og installasjonsspesifikke konfigurasjonsalternativer - sorteringer, indeksering, ytelsesjustering osv. Denne mengden alternativer er resultatet av MySQL som tilbyr langt flere funksjoner. Du må kanskje tilpasse MySQL mer, men det er sannsynlig fordi du prøver å gjøre mer i utgangspunktet.
Enbruker vs. flerbrukerdatabase
SQLite er best egnet for applikasjoner med en enkelt samtidig bruker, for eksempel en stasjonær eller mobilapp. MySQL og MariaDB er designet for å håndtere flere samtidige brukere. MySQL og MariaDB kan også tilby klyngede og skalerbare løsninger, mens SQLite ikke kan.
SQLite vs. innebygde databaser
SQLite er langt fra den eneste innebygde databasen. Mange andre leverer lignende funksjoner, men legger vekt på forskjellige brukstilfeller eller distribusjonsmodeller.
- Apache Derby: En innebygd SQL-motor, også pakket om av Oracle som Java DB. Siden Derby er skrevet på Java og krever JVM, er det hovedsakelig designet for innebygging i Java-apper.
- Firebird innebygd: Firebird-databasen, som kjører plattform og har mange avanserte funksjoner, er tilgjengelig som et bibliotek som kan bygges inn i et klientprogram. Funksjonssettet sammenlignes godt med SQLite, men SQLite har et langt større brukerfellesskap og støttebase.
- Rike: En høyytelses relasjonsdatabase designet for mobile miljøer, hovedsakelig Android, men kan også støtte skrivebordsmiljøer som Windows. Imidlertid er Realm objektbasert og bruker ikke SQL-spørringer - bra hvis du helst ikke vil bruke SQL, men dårlig hvis SQL er kjent og komfortabel.
- VistaDB: En innebygd database for. Net-kjøretiden. VistaDB er tilgjengelig i versjoner som er spesifikke for forskjellige smaker og inkarnasjoner av .Net og med mange forretningsfunksjoner som kryptering av full database. Det er imidlertid et kommersielt produkt, ikke åpen kildekode.
- Berkeley DB: Et Oracle-prosjekt, nominelt en nøkkel- / verdilager, men en som bruker SQLite i nyere utgaver som en måte å håndtere SQL-spørsmål på. Berkeley DBs underliggende databasemotor har ytelsesforbedringer som SQLite ikke kan matche, for eksempel å kunne håndtere flere samtidige skriveoperasjoner.
Når ikke SQLite skal brukes
SQLites designvalg gjør det godt egnet for noen scenarier, men dårlig egnet for andre. Her er noen steder hvor SQLite ikke fungerer bra:
- Apper som bruker funksjoner som SQLite ikke støtter. SQLite støtter ikke, og vil i mange tilfeller ikke prøve å støtte, en rekke relasjonelle databasefunksjoner. Mange er hjørnesaker, men til og med en av dem kan bryte avtalen.
- Apper som krever utskalering. SQLite-forekomster er entall og uavhengige, uten naturlig synkronisering mellom dem. De kan ikke samles sammen eller gjøres til en klynge. Enhver programvare som bruker en skaleringsdesign, kan ikke bruke SQLite.
- Apper med samtidig skriveoperasjoner fra flere tilkoblinger. SQLite låser databasen for skriveoperasjoner, så alt som involverer flere samtidige skriveoperasjoner kan føre til ytelsesproblemer. Apper med flere samtidige lesinger er imidlertid generelt raske. SQLite 3.7.0 og høyere gir skrivemodus for å gjøre flere skrivinger raskere, men det kommer med noen begrensninger. For et alternativ, betraktet Berkeley DB, nevnt ovenfor.
- Apper som trenger sterk datatyping. SQLite har relativt få datatyper - for eksempel ingen innfødt datetime-type. Dette betyr at håndhevelsen av disse typene må håndteres av applikasjonen. Hvis du vil at databasen, i motsetning til applikasjonen, skal normalisere og begrense innganger for datetime-verdier, kan det hende at SQLite ikke fungerer for deg.
