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.