Løft hætten på de fleste forretningsapplikationer, så afslører du en måde at gemme og bruge strukturerede data på. Uanset om det er en klientside-app, en app med en webfront-end eller en app til kant-enhed, er chancerne for, at den har brug for en indlejret database af en slags.
SQLite er en indlejret open source-database, skrevet i C og kan forespørges med konventionel SQL, der er designet til at dække disse brugssager og mere. SQLite er designet til at være hurtig, bærbar og pålidelig, uanset om du kun gemmer kilobyte data eller multigigabyte-klatter.
Hvor du kan bruge SQLite
En af SQLites største fordele er, at den kan køre næsten hvor som helst. SQLite er blevet porteret til en bred vifte af platforme: Windows, MacOS, Linux, iOS, Android og mere. Især Windows-brugere kan bruge forudkompilerede binære filer til almindelig Win32, UWP, WinRT og .Net. Uanset hvilket implementeringsmål der er til din app, er der sandsynligvis en version af SQLite til rådighed for den eller en måde at porte C-kildekoden til det mål på.
Apps, der bruger SQLite, behøver ikke at blive skrevet på et bestemt sprog, så længe der er en måde at binde og arbejde med eksterne biblioteker skrevet i C. SQLites binære filer er selvstændige, så de kræver ingen særlig magi at implementere - de kan simpelthen kastes i samme bibliotek som applikationen.
Mange sprog har bindinger på højt niveau til SQLite som et bibliotek og kan bruge det sammen med andre databaseadgangslag til sproget. Python, for eksempel, bundter SQLite-biblioteket som et standardudstedelseselement med lagerversionen af Python-tolken. Derudover har tredjeparter skrevet en lang række ORM'er og datalag, der bruger SQLite, så du sidder ikke fast ved at få adgang til SQLite via rå SQL-strenge (hvilket ikke kun er klodset, men også potentielt farligt).
Endelig er kildekoden til SQLite offentligt domæne, så den kan genbruges i andre programmer uden praktiske begrænsninger.
SQLite fordele
Den mest almindelige og indlysende brugssag for SQLite tjener som en konventionel, tabelorienteret relationsdatabase. SQLite understøtter transaktioner og atomadfærd, så et programnedbrud eller endda et strømafbrydelse efterlader dig ikke med en beskadiget database.
SQLite har funktioner, der findes i avancerede databaser, såsom fuldtekstindeksering og support til JSON-data. Applikationsdata, der typisk er fyldt i semistrukturerede formater som YAML eller XML, kan gemmes som SQLite-tabeller, hvilket gør det lettere at få adgang til dataene og behandle dem hurtigere.
SQLite giver også en hurtig og effektiv måde at gemme konfigurationsdata til et program på. I stedet for at analysere et filformat som YAML, kan en udvikler bruge SQLite som en grænseflade til disse filer - ofte langt hurtigere end at betjene dem manuelt. SQLite kan arbejde med hukommelsesdata eller eksterne filer (f.eks. CSV-filer), som om de var oprindelige databasetabeller, hvilket giver en praktisk måde at forespørge om disse data på.
Fordi SQLite er en enkeltstående binær, er det let at implementere med en app og flytte den med appen efter behov. Hver database oprettet af SQLite består også af en enkelt fil, som kan komprimeres eller optimeres ved hjælp af SQL-kommandoer.
Tredjeparts binære udvidelser til SQLite tilføjer endnu mere funktionalitet. SQLCipher tilføjer 256-bit AES-kryptering til SQLite-databasefiler. En anden, SQLite-Bloomfilter, giver dig mulighed for at oprette blomstringsfiltre ud fra data i et givet felt.
Mange andre tredjepartsprojekter leverer yderligere værktøj til SQLite, såsom Visual Studio Code-udvidelsen, der tillader browsing af databaser fra Visual Studio Code eller den interaktive LiteCLI-kommandolinje til SQLite. En kurateret liste over SQLite-ressourcer på GitHub indeholder mange flere.
SQLite vs. MySQL
SQLite sammenlignes mest med MySQL (eller MariaDB) - det udbredte open source-databaseprodukt, der er en hæfteklammer til nutidens applikationsstakke. Så meget som SQLite måske ligner MySQL, er der meget at adskille disse to databaser fra hinanden - og gode grunde til at favorisere den ene frem for den anden, afhængigt af brugssagen.
Datatyper
SQLite har relativt få datatyper — BLOB, NULL, INTEGER og TEXT. MySQL (eller MariaDB) har på den anden side dedikerede datatyper til datoer og tidspunkter, forskellige præcisioner af heltal og floats og meget mere.
Hvis du gemmer relativt få datatyper, eller hvis du vil bruge dit datalag til at udføre validering af dataene, er SQLite nyttigt. Men hvis du vil have dit datalag til at give sin egen validering og normalisering, skal du gå med MySQL (eller MariaDB).
Konfiguration og tuning
SQLites konfigurations- og tuningindstillinger er minimale. De fleste af de interne eller kommandolinjeflag til SQLite beskæftiger sig med kanttilfælde eller bagudkompatibilitet. Dette passer med SQLites overordnede filosofi om enkelhed: Gør standardindstillingerne velegnede til de mest almindelige brugssager.
MySQL (eller MariaDB) har en ægte skov af database- og installationsspecifikke konfigurationsmuligheder - sorteringer, indeksering, performance tuning osv. Denne rigdom af muligheder er resultatet af MySQL, der tilbyder langt flere funktioner. Du bliver muligvis nødt til at tilpasse MySQL mere, men det er sandsynligt, fordi du prøver at gøre mere i første omgang.
Enbruger versus flerbruger database
SQLite er bedst egnet til applikationer med en enkelt samtidig bruger, såsom en desktop- eller mobilapp. MySQL og MariaDB er designet til at håndtere flere samtidige brugere. MySQL og MariaDB kan også tilbyde klyngede og skalerbare løsninger, mens SQLite ikke kan.
SQLite vs. indlejrede databaser
SQLite er langt fra den eneste integrerede database. Mange andre leverer lignende funktioner, men fremhæver forskellige brugssager eller implementeringsmodeller.
- Apache Derby: En indlejret SQL-motor, også pakket om af Oracle som Java DB. Da Derby er skrevet i Java og kræver JVM, er det primært designet til indlejring i Java-apps.
- Firebird Embedded: Firebird-databasen, der kører på tværs af platforme og har mange avancerede funktioner, er tilgængelig som et bibliotek, der kan integreres i et klientprogram. Dets funktionssæt kan sammenlignes godt med SQLite, men SQLite har et langt større brugerfællesskab og supportbase.
- Rige: En højtydende relationsdatabase designet til mobile miljøer, hovedsageligt Android, men kan også understøtte desktop-miljøer som Windows. Imidlertid er Realm objektbaseret og bruger ikke SQL-forespørgsler - godt, hvis du hellere ikke vil bruge SQL, men dårligt, hvis SQL er kendt og behagelig.
- VistaDB: En indbygget database til .Net-runtime. VistaDB fås i versioner, der er specifikke for de forskellige varianter og inkarnationer af .Net og med mange virksomhedsfunktioner som fuld databasekryptering. Det er dog et kommercielt produkt, ikke open source.
- Berkeley DB: Et Oracle-projekt, nominelt et nøgle- / værdilager, men et, der bruger SQLite i nyere udgaver som en måde at håndtere SQL-forespørgsler på. Berkeley DBs underliggende databasemotor har præstationsforbedringer, som SQLite ikke kan matche, såsom at være i stand til at håndtere flere samtidige skriveoperationer.
Hvornår skal man ikke bruge SQLite
SQLites designvalg gør det velegnet til nogle scenarier, men dårligt egnet til andre. Her er nogle steder, hvor SQLite ikke fungerer godt:
- Apps, der bruger funktioner, som SQLite ikke understøtter. SQLite understøtter ikke, og vil i mange tilfælde ikke forsøge at understøtte, en række relationelle databasefunktioner. Mange er hjørnesager, men selv en af dem kan bryde aftalen.
- Apps, der kræver skaleringsdesign. SQLite-forekomster er ental og uafhængige uden indbygget synkronisering mellem dem. De kan ikke samles sammen eller gøres til en klynge. Enhver softwareapplikation, der bruger et skaleringsdesign, kan ikke bruge SQLite.
- Apps med samtidige skriveoperationer fra flere forbindelser. SQLite låser databasen til skriveoperationer, så alt, der involverer flere samtidige skriveoperationer, kan resultere i ydeevneproblemer. Apps med flere samtidige læsninger er dog generelt hurtige. SQLite 3.7.0 og nyere giver tilskrivning-for-gang-logningstilstand for at få flere skrivninger til at fungere hurtigere, men det har nogle begrænsninger. For et alternativ, betragtet som Berkeley DB, nævnt ovenfor.
- Apps, der har brug for stærk datatypning. SQLite har relativt få datatyper - f.eks. Ingen indfødt datetime-type. Dette betyder, at håndhævelsen af disse typer skal håndteres af applikationen. Hvis du ønsker, at databasen i modsætning til applikationen skal normalisere og begrænse input til datetime-værdier, fungerer SQLite muligvis ikke for dig.
