[C++] Advies, welke database library?

[kvdveer]

Om mijn kennis van c++ maar eens wat op te krikken ben ik begonnen met het schrijven van een character generator voor Dungeons and Dragons. De logica begint nu aardig vorm te krijgen, maar ik voorzie een probleem met de data: het gaat om enorme hoeveelheden kleine records waarop veel kleine bewerkinkjes uitgevoerd gaan worden (read only). Momenteel werk ik met gecompileerde data(grote array's), maar dat is natuurlijk niet schaalbaar. Om de applicatie distribueerbaar te maken wil ik geen database daemon (mysql, postgresql) gebruiken. Ook heb ik de features in SQL vrijwel niet nodig: bijna al mijn queries zouden er namelijk uit zien als "SELECT veld FROM tabel WHERE veld2='waarde' ".
Ik kan natuurlijk zelf een of ander formaatje schrijven - gezien de eenvoud van de data is dat niet eens zo moeilijk, maar het is natuurlijk slimmer om een voorgebouwde database library te gebruiken. Ik heb al zitten kijken naar SQlite, db3 en heel even db4. Ik heb echter niet echt een vergelijking tussen die drie kunnen vinden, en ik weet ook niet of er misschien nog andere kandidaten zijn. Ik heb met geen van allen ervaring.

Mijn eisen zijn ongeveer als volgt:
[list]• Het moet een library zijn - geen client voor een daemon of zo.
• Goede performance op lezen, schrijven boeit me niet.
• (L)GPL-compatible licence, of op zijn minst OSI-approved.
• Datatypen: Blob,int,float en char. (daarmee valt sqlite eigenlijk af, al zijn er workarounds)
• Cross platform. (linux, windows)


De vraag drumroll please
Welke database library zouden jullie hiervoor adviseren?

offtopic:
Voordat fanatieke XML-ers hun advies uit gaan brengen: XML valt als opslagformaat af omdat dat de performance te ernstig zou aantasten.

[PommeFritz]

Waarom valt SQlite af?
http://www.sqlite.org/datatype3.html

[Zoijar]

Wat is "enorm veel"?

En structuur? Als het een boom is zou ik alsnog een xml file in je geheugen lezen...Als het allemaal losse key/value pairs zijn, kan je misschien gewoon een hash table opslaan en inlezen om snel te zoeken. (ie. je memory mapped een hash table, dan heb je geen laad tijd, en behoorlijk snelle zoektijd)

[ Voor 105% gewijzigd door Zoijar op 09-01-2005 13:36 ]

[kvdveer]

PommeFritz schreef op zondag 09 januari 2005 @ 13:25:
Waarom valt SQlite af?
http://www.sqlite.org/datatype3.html

Omdat Sqlite geen ondersteuning heeft voor BLOBs (die site liegt!). Je kunt wel een binaire lap opslaan, maar dan moet je dat eerst gaan coderen, en daarna decoderen. Dat is geen ondersteuning, maar een workaround.

Zoijar schreef op zondag 09 januari 2005 @ 13:28:
Wat is "enorm veel"?

Goeie vraag. Ik vermoed dat mijn database in binaire vorm ongeveer 5 tot 10 megabyte groot zal zijn, het gaat om ca. 10.000 tot 100.000 records. Strikt genomen is dat niet zo heel groot, maar als je het meecompileert in headerfiles is dat plotseling aardig wat...

Momenteel zien mijn records er ongeveer als volgt uit:

code:

prop(propIdType, propGroupType, double, char*, char*, bool, propIdType, void*)
prob(propIdType, propIdType, bool, double, uint32);

Die char*'s en void* zijn meestal null, op die idTypes ga ik zoeken.

[ Voor 53% gewijzigd door kvdveer op 09-01-2005 15:50 ]

[PommeFritz]

kvdveer schreef op zondag 09 januari 2005 @ 13:29:Omdat Sqlite geen ondersteuning heeft voor BLOBs (die site liegt!). Je kunt wel een binaire lap opslaan, maar dan moet je dat eerst gaan coderen, en daarna decoderen. Dat is geen ondersteuning, maar een workaround.

Waar lees jij dat dan dat je dat moet doen?
Voor zover ik kan zien, ook hier http://www.sqlite.org/capi3.html , kun je gewoon een void* erin knallen. En in de FAQ staat dat hij gewoon Blobs ondersteunt.

(disclaimer: ik heb tot nu toe alleen Sqlite 2 gebruikt, vanuit Python, dus geen ervaring met de nieuwe sqlite 3 features. Blobs gebruik ik niet, ik sla een file naam op en de "blob" lees ik dan apart in van disk, gewoon externe files dus).

Maar eh, als je afknapt op Sqlite, moet je misschien Sleepycat's BerkelyDB eens bekijken. Maar dan heb je geen SQL.

[kvdveer]

PommeFritz schreef op zondag 09 januari 2005 @ 16:58:
[...]

Waar lees jij dat dan dat je dat moet doen?
Voor zover ik kan zien, ook hier http://www.sqlite.org/capi3.html , kun je gewoon een void* erin knallen. En in de FAQ staat dat hij gewoon Blobs ondersteunt.

(disclaimer: ik heb tot nu toe alleen Sqlite 2 gebruikt, vanuit Python, dus geen ervaring met de nieuwe sqlite 3 features. Blobs gebruik ik niet, ik sla een file naam op en de "blob" lees ik dan apart in van disk, gewoon externe files dus).

Maar eh, als je afknapt op Sqlite, moet je misschien Sleepycat's BerkelyDB eens bekijken. Maar dan heb je geen SQL.

Uit de 2.x documentatie, die ik een jaar geleden ergens voor moest lezen... Ik zie nu dat dit probleem opgelost is...

Uit de faq van sqlite
(12) Does SQLite support a BLOB type?
SQLite version 3.0 lets you puts BLOB data into any column, even columns that are declared to hold some other type.

SQLite version 2.8 will store any text data without embedded '\000' characters. If you need to store BLOB data in SQLite version 2.8 you'll want to encode that data first. There is a source file named "src/encode.c" in the SQLite version 2.8 distribution that contains implementations of functions named "sqlite_encode_binary() and sqlite_decode_binary() that can be used for converting binary data to ASCII and back again, if you like.

[JaWi]

SQLite3 heeft inderdaad standaard support voor BLOBs. Je kunt hiervoor de API-calls sqlite_prepare() en sqlite_bind_blob() gebruiken. Wat de TS waarschijnlijk bedoeld met "liegen" is de query:

SQL:

INSERT INTO bla VALUES ( X'ABCD' );

waarin X'ABCD' de hex-representatie van je code is. Dit werkt ook, maar vereist dus dat je zelf je code als hex-data aanbiedt.

Als je alleen queries in de vorm van:

SQL:

SELECT a FROM table WHERE b='value';

dan kun je misschien -zoals al eerder gesuggereerd is- beter kijken naar BerkeleyDB, waarmee je direct hash-tables kunt opzetten.