Is there an SQL implementation that works well on lower end embedded projects? ARM7/Cortex type devices are primary what I am looking at. These chips can barely run a version of uCLinux, so SQLite isn't exactly an options.
Was curious what, if any options are available for something like this.
I am guessing most implementations will require too much memory to be of use here.
--------------------------------------- Posted through
There are SQL preprocessors available for a number of languages and various DBMS which generate compilable functions from static queries embedded into the program source. This is as light as SQL gets. But preprocessors don't work for ad hoc query construction.
SQLite is about as small as a runtime SQL implementation can get - the minimal configuration - about 250KB on x86 - consists of little more than a simple SQL language interpreter, basic query constructor and library functions.
A good question to ask is whether you really need a query *language* or just a storage API. Unless your program needs ad-hoc query generation or the database needs a standard face because it will be accessible outside of the program, there is little reason to pay for the overhead of a generalized DDL/DML interpreter and query constructor/optimizer.
For most work, a persistent key/value or graph store generally suffices. Even if the program computes complex relations, as long as they are known during development, they almost always can be programmed more efficiently than anything a general query constructor can generate regardless of optimization.
There are a number of key/value and graph store databases, with or without ACID transactions. A good place to start looking is at
For key/value with maximum control, you can roll your own using one of the file oriented B/B+/B*-tree or hash libraries. Unless you need ACID transactions, this probably is the best option for small and fast.
Are you sure you need the RDBMS and not just a *client*? (i.e., do the relations *need* to reside on/in your device or can they reside "elsewhere" and your device simply *query* them?)
If all you need is a *client*, this is relatively easy (depending on how much processing you want to do in the client vs. in the server).
OTOH, if you actually *do* want the RDBMS to reside *in* your device, then you need to define the sizes and complexities of the relations you want to store/maintain, how hard you will hammer on the RDBMS, how quickly you want your results, etc.
I am a big fan of table-driven software and have been experimenting with moving those (ahem) "tables" into formal RDBMS's to see how the consequences (time/space/reliability/maintenance/flexibility/etc.) shake out. (so far, time and space are *big* performance hits -- as can be expected -- but the other issues are proving delightfully worthwhile!)