FAQ
overview | tutorial | download | API | misc | faq | license
How does d_store compare to SQL?
I'm claiming that d_store has the same (and more) query power as SQL has. However, most complex SELECTS with JOINs and GROUP BYs and ORDER and LIMIT etc, you will have to implement yourself with d_select and set operations, maybe even iterating and aggregating your results. But unless you choose the wrong algorithm, this will still be fast, and nothing different from what the SQL engine has to do.
However, for d_store, you will have to do this manually, writing 'the query' by manipulating sets. And SQL does that part for you; you just come up with the right query.
But at one point, when your query is so complex it needs to turn into a couple of queries, d_store will become more and more attractive.
And SQL provides the whole ACID (Atomicity, Consistency, Isolation, and Durability; and this is not connected to SQL as a query language persé, but to the engines or servers that implement it), which guarantees some safety and consistency about your data. Which d_store does not do at all.
Also, an SQL database can be shared among many processes, which d_store cannot.
Another thing is that d_store doesn't have this notion of tables. The example on the main page almost simulates this by using the first field of all rows as the person identifier and the second field as the type of the row. Which translates into two tables: a 'name' table and a 'tel' table, where the last one uses the name.id as a foreign key.
However, if you really want tables, creating multiple database would then be the way to go. Your keys will automatically have indexes associated with them, as values can cross different databases in d_store.
So when to actually choose SQL over d_store?
- if you store more data then you can fit in memory;
- if your data continuously grows, potentially beyond what might fit in memory.
- if your data is shared with other processes, or even remote clients.
- if you firmly prefer SQL over programatically doing set operations, and d_select's
How does d_store compare to sqlite?
Sqlite is a very mature SQL engine, which does not have the overhead of being in a different process, making iterating, boxing and unboxing and escaping your data a lot faster then a dedicated server. Its purpose is to be embedded into applications, and it will work nicely under memory constraints.
It can use a file as the persistent store (it can also be in memory only), which can be shared and is safe from crashes by journalling and such techniques. (This will be provided by d_store one day too, but for now it doesn't have this.)
And of-course it uses SQL as the query language, see the above question for a discussion around that.
Basically sqlite and d_store share some of their goals, so when to choose sqlite: (again read above question also for the generic SQL reasons)
- if the data is shared among multiple processes or multiple threads
- if the data needs to be persistent and safe on disk (d_store should provide that also one day, but not right now)
So why choose d_store?
- Because it provides more direct and faster access to the stored data, making displaying the data in the UI less expensive, also enabling features like live string searching.
- There is no overhead from parsing SQL, or keeping prepared queries around, also there is no need to escape or unescape data.
- All values are shared, so having a 100 mp3's from the same artiest, stores that artiest name only once. To get this from sqlite, you need to tear it up into a normal form, which is reasonably more expensive to query (and cumbersome to use).
- You can store arbitrary binary things, including pointers in d_store.
How does d_store compare to a unix db (berkelydb)?
Berkeleydb or other unix dbs provide on disk, safe, hash-tables (or other structures) that can store almost anything. But other then the primary access key, and, for some variants, programatically defined indexes, there are no relation or other things you can query.
So d_store and berkeleydb share that you can put in arbitrary data, including structs.
But berkeleydb can work on huge databases, and d_store is always limited to the size of the main memory.
how does d_store compare to an applications own set of hash tables and lists?
D_store provides a debugged and (and for now only somewhat) optimized data engine. It has a friendly API and will fit in a lot of situations.
Of-course, d_store can never become as tuned as well chosen internal data structures. And d_store cannot provide certain things custom data structures can.
On the other side, at points in time, you might need to rework all your internal data structures, just because you want to add a feature that doesn't really fit yet. D_store might prove to be more flexible, and maybe provide certain features for free. As the alternative to turning the custom data structures more and more into a database engine of themselves.
You should also consider that d_store can play nicely with your own structures, it can work with and store pointers and random data structs,
Last modified: 2007-11-19 20:17 GMT