Embedded SQL implementations

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 http://www.EmbeddedRelated.com

On Wed, 15 Sep 2010 14:44:31 -0500, "Raddix"
<rudigersv03@n_o_s_p_a_m.yahoo.com> wrote:

>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.	   

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
http://nosql-database.org/.  

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.

Hope this helps.
George

Raddix wrote:
> 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.	   

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!)

Op Wed, 15 Sep 2010 21:44:31 +0200 schreef Raddix  
<rudigersv03@n_o_s_p_a_m.yahoo.com>:
> 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.	

Polyhedra FlashLite DBMS
http://www.enea.com/Templates/Product____27040.aspx


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)