On Wednesday, 1 June 2016 at 05:45:49 UTC, Piotrek wrote:
On Tuesday, 31 May 2016 at 22:08:00 UTC, Stefan Koch wrote:
Nice effort. How would you like collaboration with the SQLite-D project.


Thanks. Correct me if I'm wrong but SQLite-D is a compile time SQLite3 file reader. If so, I can predict not many common parts. Maybe the one would be a data deserialization component however I didn't check how it's done in SQLite-D.

I intend for it to be a complete replacement for SQLite.
Therefore I can see facing many common problems.
Keeping B-Trees roughly balanced.
Providing a nice query interface and so on.
With has similar goals albeit file format compatible to SQLite.

When I was selecting possible file format I was thinking about SQLite one. I am actually a fan of the SQLite project. However there are some shortcomings present in current SQlite3 format:

- SQlite3 is not really a one file storage (i.e. journal file)
- it gets fragmented very quickly (check out design goals for SQLite4) - it's overcomplicated and non deterministic with respect to real time software - it has unnecessary overhead because every column is actually a variant type

Add to this the main goal of replacing SQL with D ranges+algorithms.
This is SQLite-D's goal as well.
In result it turned out it would be great to have an alternate format.

Piotrek

Well I can see the non-realtime property being a factor for every database.


Reply via email to