Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 19 reacties
Bron: SQLite

SQLite is een in c ontwikkeld databasesysteem dat als database voor onder meer websites en embedded applicaties is te gebruiken. Volgens de ontwikkelaars heeft SQLite geen installatie en administratie nodig, ondersteunt het databases tot een omvang van twee terabyte en wordt een volledige database in één bestand opgeslagen. Verder ondersteunt het bijna de volledige SQL92-specificatie en is het eenvoudig via onder andere Tcl/Tk aan te sturen. De ontwikkelaar heeft enkele dagen geleden versie 3.7.2 met de volgende lijst aanpassingen de deur uit gedaan:

Version 3.7.2:
  • Fix an old and very obscure bug that can lead to corruption of the database free-page list when incremental_vacuum is used.
Version 3.7.1:
  • Added new commands SQLITE_DBSTATUS_SCHEMA_USED and SQLITE_DBSTATUS_STMT_USED to the sqlite3_db_status() interface, in order to report out the amount of memory used to hold the schema and prepared statements of a connection.
  • Increase the maximum size of a database pages from 32KiB to 64KiB.
  • Use the LIKE optimization even if the right-hand side string contains no wildcards.
  • Added the SQLITE_FCNTL_CHUNK_SIZE verb to the sqlite3_file_control() interface for both unix and windows, to cause database files to grow in large chunks in order to reduce disk fragmentation.
  • Fixed a bug in the query planner that caused performance regresssions relative to 3.6.23.1 on some complex joins.
  • Fixed a typo in the OS/2 backend.
  • Refactored the pager module.
  • The SQLITE_MAX_PAGE_SIZE compile-time option is now silently ignored. The maximum page size is hard-coded at 65536 bytes.
Version 3.7.0.1:
  • Fix a potential database corruption bug that can occur if version 3.7.0 and version 3.6.23.1 alternately write to the same database file. Ticket [51ae9cad317a1]
  • Fix a performance regression related to the query planner enhancements of version 3.7.0.
Version 3.7.0:
  • Added support for write-ahead logging.
  • Query planner enhancement - automatic transient indices are created when doing so reduces the estimated query time.
  • Query planner enhancement - the ORDER BY becomes a no-op if the query also contains a GROUP BY clause that forces the correct output order.
  • Add the SQLITE_DBSTATUS_CACHE_USED verb for sqlite3_db_status().
  • The logical database size is now stored in the database header so that bytes can be appended to the end of the database file without corrupting it and so that SQLite will work correctly on systems that lack support for ftruncate().
Versienummer:3.7.2
Releasestatus:Final
Besturingssystemen:Windows 7, Windows 9x, Windows NT, Windows 2000, Linux, BSD, Windows XP, DOS, macOS, Solaris, UNIX, Windows Server 2003, Windows Vista, Windows Server 2008
Website:SQLite
Download:http://www.sqlite.org/download.html
Licentietype:Voorwaarden (GNU/BSD/etc.)
Moderatie-faq Wijzig weergave

Reacties (19)

ik vraag me altijd af hoe snel dit is, in vergelijking tot, zeg een map met txt files.

zou dit met een aantal 'mods' bijv. gconf kunnen vervangen of sterker nog /etc
onder linux,

verder zijn er tal van aplicaties onder windows die best eens aangepast kunnen worden om hier gebruik van te maken, er zijn zat linux apps die onder windows het zelfdfe (alles in een text file) gedrag vertonen terweil windows zich daar een stuk minder goed voor leent.
Op het moment dat je een configuratie-file hebt die slechts beperkt wijzigt en alleen ingelezen wordt bij het opstarten van de applicatie (of na een signaal dat de file opnieuw gelezen moet worden), dan heb je weinig voordeel van SQLite. In het geval van Posix-like besturingssystemen vind ik het eerder een nadeel als de configuratie in een SQLite-database geplaatst zou worden, omdat je dan niet meer simpel met een tekst-editor de instellingen kan wijzigen...

Op het moment dat je echter een sterk muterende dataset hebt, die ook weer erg regelmatig uitgelezen moet worden (denk hierbij aan programma's die bepaalde gegevens loggen), dan kan SQLite een goede vervanger zijn. Zo gebruikt bijvoorbeeld Firefox SQLite om zaken als geschiedenis en cookies op te slaan, zeker in het geval van de geschiedenis is het goed en snel kunnen doorzoeken van deze gegevens noodzakelijk voor een goed werkende "awesome bar".

Ook wanneer je geen zorgen wilt maken over escaping van bepaalde karakters (denk aan newlines, en isgelijk-tekens in een MS-Windows INI-file), kan het gebruik van SQLite het gemakkelijker maken om bepaalde zaken op te slaan in een bestand...
Dat wijzingen probleem is natuurlijk een eitje om op te lossen: je maakt een applicatie die export naar text en import van regelt, en zelfs je default editor opstart, zoals o.a. crontab dat kan doen.
Cron gebruikt gewoon text bestanden hoor.
*zucht*, ja, dat weet ik. Het gaat om crontab -e. Normaal ga je niet direct zelf de textbestanden zitten tweaken maar doe je of crontab -l > bestand.txt, vi bestand.txt, crontab bestand.txt of crontab -e

Als je het op die manier doet maakt het niets uit hoe crontab de data zelf opslaat.
sqlite is behoorlijk snel. Als ik op mijn linux systeem een sqlite database aanmaak onder /dev/shm en ik zet er 100.000 records in, dan kan ik met een PHP scriptje op basis van een random primary key SELECT grofweg een snelheid van 30.000 queries per seconde halen.

Overigens is het opslaan van configuratiebestanden in plain text files een filosofie in *unix:
"Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. Under classic Unix, as many programs as possible are written as simple filters, which take a simple text stream on input and process it into another simple text stream on output."
"Query planner enhancement - the ORDER BY becomes a no-op if the query also contains a GROUP BY clause that forces the correct output order."

(ik heb een Oracle pet - be gentle!)
Volgens mij is een GROUP BY NIET automatisch een ORDER BY.
Een veel voorkomende fout, in Oracle althans, is impliciet uitgaan van een sortering bij GROUP BY's. Bij migraties naar 10G/11G hebben wij allerlei scans moeten doen op code die hier van uitging.
In Oracle is sortering alleen gegarandeerd als je ORDER BY gebruikt !!! (ik weet ook dat de uitvoer bij gebruik van GROUP BY in 99% van de gevallen wel gesorteerd is)


Natuurlijk kan deze impliciete implementatie van een ORDER BY in geval van GROUP BY door de leverancier/ontwikkelaar geimplementeerd zijn (zoals bij sqllite).
Wellicht dat ze intern checken of er een GROUP BY aanwezig is (if [..] also contains a) de boel al sorteert zoals ORDER BY hoort te doen (forces the correct output order). Als dat het geval is, dan is het resultaat al gesorteerd en is de ORDER BY qua code overbodig. Dit is dus een interne optimalisatie die Oracle mogelijk al lang heeft gedaan in hun code.
Voor zover ik weet staat er in de SQL92 specificatie geen regel die stelt in welke volgorde de resultaten van een GROUP BY moeten worden teruggegeven.

Met dat in het achterhoofd is de wijziging goed te begrijpen: een GROUP BY wordt vaak ge´mplementeerd door eerst een sortering toe te passen, met als gevolg dat de resulterende set ook gesorteerd is. Omdat de developers van SQLite zelf de keuze hebben gemaakt om een GROUP BY altijd gesorteerd terug te geven, kunnen ze de keuze maken om een ORDER BY een no-op te maken.

Ze zeggen dus niet dat je geen ORDER BY meer hoeft te gebruiken; ze zeggen alleen dat de SQL engine, zodra je zowel een GROUP BY en een ORDER BY op dezelfde kolommen uitvoert, de ORDER BY niet langer hoeft uit te voeren. Het resultaat is 100% identiek.
Dit geldt voor alle databases, zonder ORDER BY is er geen specifieke sortering al kan het toevallig (!!!) een gewenste sortering opleveren. En dan ineens komt er een nieuwere versie met een andere/betere queryplanner, en ligt de "sortering" overhoop...

Zonder ORDER BY is er geen gewenste sortering opgegeven, alles wat de query oplevert, is dus in de juiste volgorde opgeleverd. Het kan namelijk niet fout zijn, anders had je wel een ORDER BY in de query gezet.

Dat de queryplanner het sorteren overslaat wanneer de data dankzij het queryplan al is gesorteerd, dat is mooi, maar dat maakt niet uit voor het eindresultaat. Het is hooguit wat sneller.
Waarom staat erbij licenties "Voorwaarden (GNU/BSD/etc.)" terwijl SQLite gewoon Public Domain is, als ik Wikipedia tenminste mag geloven.

Verder is SQLite handig voor database in toepassingen waar een extra database server niet wenselijk is.
Ik heb een keer gehoord dat sqlite software is die super goed getest is en die 1 van de weinigste bugs bevat. Uit drie updates blijkt dat wel. 3 updates totaal 3 bugs verholpen.

Een bron: http://www.sqlite.org/testing.html
Van hun eigen site :P

[Reactie gewijzigd door mokkol op 14 september 2010 11:29]

Je kan zelf vreemde bugs introduceren in je programma's doordat SQLite nog al vreemd omspringt met data types, zo kan je (dacht ik) bijvoorbeeld een string van 12 characters in een char(10) drukken en nog meer van dat soort vreemde dingen.

Elke keer als ik het gebruik loop ik in ieder geval weer tegen dingen aan dat ik denk van wat gebeurt hier nou weer. Het is wel de ideale database voor lokale applicaties doordat alles zich binnen 1 file bevind, bestandje overkopieŰren, plakken.. en je hebt de exact zelfde database.

//

Er zijn trouwens wel veel, maar weinige goede GUI tools for Sqlite te vinden, waar je bij MySQL, MySQL workbench hebt en bij PostgreSQL pgAdmin kom je hier een beetje bedrogen uit waar bij voor de meeste tools betaald moet worden of ze werken gewoon niet fijn (naar mijn mening uiteraard ;))
Dus als iemand een tool zoekt om hier mee te werken, Sqlite Expert is een goede gratis optie. Sqlite Developer is beter/uitgebreider maar alleen een gratis trial van verkrijgbaar
Ik gebruik al een hele tijd de cross platform firefox plugin Sqlite Manager:
https://addons.mozilla.org/en-US/firefox/addon/5817/

Werkt ook op de Mac en Linux (ik draai geen windows, maar wel deze platformen)
Vergeten te vermelden, gebruik het zelf ook onder Linux (openSUSE) maar die ontbreekt wel weer de geavanceerdere mogelijkheden zoals het makkelijk instellen van triggers en dergelijke.
offtopic:
never mind

[Reactie gewijzigd door SWINX op 15 september 2010 01:38]

inderdaad, ik wou ook reageren maar het is het niet waar denk ik.
Voor de volledigheid: versie 3.7.2 is niet 'enkele dagen' maar drie weken geleden (24 augustus) uitgekomen. Zie http://www.sqlite.org/news.html
(Verder niets dan lof dat dit pracht product weer eens onder de aandacht wordt gebracht.)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True