Re: [sqlite] DeviceSQL

[Nicolas Williams]

On Fri, Dec 14, 2007 at 04:28:07PM -0600, John Stanton wrote:
> Samuel R. Neff wrote:
> >I'm not sure I see added value in incorporating procedural SQL in an
> >embedded database like SQLite or DeviceSQL.  Isn't the easily extensible
> >mechanism that SQLite has for creating custom functions in the host 
> >language [...]
> 
> The difference is if you are pursuing the DeviceSQL approach and 
> compiling a library of data manipulation functions.  The partitioning is 
> cleaner if procedural logic can be included in those functions.
> 
> In our Sqlite applications we have implemented Javascript as a DB 
> procedural language by adding an Sqlite class.  You can store it in the 
> DB and execute it.  You can also run Javascript scripts which manipulate 
> an Sqlite DB.  When using Sqlite we see the value of a DB procedural 
> language in the dynamic storage of rules rather than having rules 
> chiselled in stone in the application code.  Multiple rules in 
> Javascript can be integrated and compiled into one executable procedure, 
> giving great flexibility in building systems in the "expert" style.
> 
> We chose Javascript for practical reasons.  It is universally used in 
> WWW pages so the developers do not have any new language to learn.

SQL is very expressive, and procedural SQL is too.  Much more so that C.
So if you're writing an embedded app in C then procedural SQL might come
in handy (also, the VDBE code will probably be smaller than the
corresponding object code).

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[John Stanton]

Samuel R. Neff wrote:

-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 14, 2007 3:55 PM

To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL

... is it not 
directly comparable to DeviceSQL unless the external compiler handles 
not only SQL but also PL/SQL.  The addition of the command language 
allows for creating a library of data manipulation functions rather than 
just embedded SQL.  ...




John,

I'm not sure I see added value in incorporating procedural SQL in an
embedded database like SQLite or DeviceSQL.  Isn't the easily extensible
mechanism that SQLite has for creating custom functions in the host language
(C, C#, ActionScript, whatever) a fully valid replacement for whatever
procedure language could be provided through VDBE?  Also doesn't the fact
that SQLite (and any embedded db) runs in-process negate the importance of
SQL procedural code?  In my experience, stored procedures are usually used
to offload more work to the DB server and thus perform DB intensive code
closer to where the DB data is, which is not necessary when the DB is
already in-process?  


After moving from MSSQL to SQLite for our application, which previously used
stored procedures, we've never missed the functionality of TSQL and found
creating UDFs in C# for SQLite much easier and more powerful that using TSQL
UDFs, especially 'cause they run in-process and thus have full access to the
host application's objects and code.

Sam

The difference is if you are pursuing the DeviceSQL approach and 
compiling a library of data manipulation functions.  The partitioning is 
cleaner if procedural logic can be included in those functions.


In our Sqlite applications we have implemented Javascript as a DB 
procedural language by adding an Sqlite class.  You can store it in the 
DB and execute it.  You can also run Javascript scripts which manipulate 
an Sqlite DB.  When using Sqlite we see the value of a DB procedural 
language in the dynamic storage of rules rather than having rules 
chiselled in stone in the application code.  Multiple rules in 
Javascript can be integrated and compiled into one executable procedure, 
giving great flexibility in building systems in the "expert" style.


We chose Javascript for practical reasons.  It is universally used in 
WWW pages so the developers do not have any new language to learn.


---
We're Hiring! Seeking a passionate developer to join our team building Flex
based products. Position is in the Washington D.C. metro area. If interested
contact [EMAIL PROTECTED]
 



-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] DeviceSQL

[Samuel R. Neff]

-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 14, 2007 3:55 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL

... is it not 
directly comparable to DeviceSQL unless the external compiler handles 
not only SQL but also PL/SQL.  The addition of the command language 
allows for creating a library of data manipulation functions rather than 
just embedded SQL.  ...



John,

I'm not sure I see added value in incorporating procedural SQL in an
embedded database like SQLite or DeviceSQL.  Isn't the easily extensible
mechanism that SQLite has for creating custom functions in the host language
(C, C#, ActionScript, whatever) a fully valid replacement for whatever
procedure language could be provided through VDBE?  Also doesn't the fact
that SQLite (and any embedded db) runs in-process negate the importance of
SQL procedural code?  In my experience, stored procedures are usually used
to offload more work to the DB server and thus perform DB intensive code
closer to where the DB data is, which is not necessary when the DB is
already in-process?  

After moving from MSSQL to SQLite for our application, which previously used
stored procedures, we've never missed the functionality of TSQL and found
creating UDFs in C# for SQLite much easier and more powerful that using TSQL
UDFs, especially 'cause they run in-process and thus have full access to the
host application's objects and code.

Sam


---
We're Hiring! Seeking a passionate developer to join our team building Flex
based products. Position is in the Washington D.C. metro area. If interested
contact [EMAIL PROTECTED]
 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[John Stanton]

We did that with our products which used byte code.  Byte code compiled 
on earlier versions would run on later ones, but new code with the extra 
opcodes would not run on old interpreters.  It protected customers who 
had lost their source code or were afraid to recompile after an upgrade 
because of version control blunders.


Noah Hart wrote:

Why can't new OP codes be simply added to the end, so that the
serializations will always work?

Noah 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 14, 2007 8:20 AM

To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL
Importance: High

Case in point:  A new opcode has been added for the pending 3.5.4
release.  And this caused many of the other opcodes to be
automatically renumbered.  A serialization created for 3.5.3
has little hope of running on 3.5.4.

--
D. Richard Hipp <[EMAIL PROTECTED]>




CONFIDENTIALITY NOTICE: 
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.





-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[John Stanton]

Dennis, your application may not be a microwave oven but it does appear 
to be "deeply embedded" as opposed to a general purpose DB server which 
handles generic queries.


I was aware of the runtime only version of Sqlite, but is it not 
directly comparable to DeviceSQL unless the external compiler handles 
not only SQL but also PL/SQL.  The addition of the command language 
allows for creating a library of data manipulation functions rather than 
just embedded SQL.  My point was that the DeviceSQL approach could be 
used with Sqlite to produce a smaller footprint embedded product and 
that such a product has the potential of being less memory hungry than 
DeviceSQL simply by virtue of the higher information density of the VDBE 
target code compared to native machine instructions.


Dennis Cote wrote:

John Stanton wrote:


DeviceSQL is not suitable for general purpose SQL processing, unlike 
Sqlite, and should only be compared as an alternative in deeply 
embedded applications so the only useful comparison is one which looks 
like a cell phone, microwave oven or a TV set top box.




The application doesn't necessarily have to look like a microwave. :-)

It could be any application that uses a fixed set of predetermined SQL 
statements to perform its operations. My primary application does 
exactly that using SQLite with all statements prepared and cached as 
needed. It runs on a standard PC under Windows. We have no need for 
executing arbitrary, runtime generated, or user supplied SQL as many 
other applications do. Every SQL statement that can be executed is known 
before the application starts.


I can imagine that a version of Sqlite which does not include its SQL 
compiler and which uses precompiled VDBE code would provide similar 
functionality to DeviceSQL, particularly if the Sqlite compiler were 
extended to generate VDBE from PL/SQl.  I can imagine that the higher 
information density of the VDBE code could deliver the advantage =of a 
smaller memory footprint.


I thought that this already existed as a commercial product that Richard 
offered, but I can't find any reference to it on the paid support page 
at http://www.hwaci.com/sw/sqlite/prosupport.html. My recollection was 
an offline compiler that ran on a PC and generated VDBE code to execute 
SQL statements, along with source code for a runtime execution engine 
that would execute those pre-compiled statements. The execution engine 
could be built for any target, and was much smaller than SQLite because 
it eliminated the parser and code generator functionality. Does this 
exist, or was I just imagining it?


Dennis Cote

- 


To unsubscribe, send email to [EMAIL PROTECTED]
- 






-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Steven Fisher]

On 14-Dec-2007, at 5:41 AM, Clay Dowling wrote:


I have to say, this discussion has been very informative, although
probably not in a way that would make mr Weick happy.  I've certainly
learned a lot about encirq that tells me what I need to know about  
doing

business with them.


Same thought here. Kudos to D. Richard Hipp for keeping his cool under  
provocation.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Dennis Cote]

[EMAIL PROTECTED] wrote:

Dennis Cote <[EMAIL PROTECTED]> wrote:
  
It could be any application that uses a fixed set of predetermined SQL 
statements to perform its operations. My primary application does 
exactly that using SQLite with all statements prepared and cached as 
needed. It runs on a standard PC under Windows. We have no need for 
executing arbitrary, runtime generated, or user supplied SQL as many 
other applications do. Every SQL statement that can be executed is known 
before the application starts.





Your application uses a fixed set of SQL statements now.  But
that set of statements might change in the next release. Or you
might change or modify a table, or add an index.  


A key feature SQLite is that these changes preserve the file
format.  With other systems, when you change the schema the
file format changes with it.
  


Yes, of course. We can also generally use SQL to "upgrade" existing 
database files to the new schema quite easily using SQLite.


One of the ideas I try to push is SQLite as an Application File 
Format.  The idea is that you put your information in an SQLite 
database file and it is then readable by diverse, general-purpose 
tools, and across multiple releases.  Sure, the schema might

change from one release to the next, but the data is still
easily accessible.

  


The biggest problem I see with this concept right now is that if you use 
any custom functions or collations you really can't work with your 
database using diverse, general purpose tools. If you have triggers or 
views that call these custom functions then you have difficulties 
accessing the data from any other application, especially third party 
database browsers etc.


That is the principal reason I think it would be very useful to extend 
the base set of functions and collations that are universally available 
to all applications using SQLite to access a database file. Things like 
graphical browser applications, where code size really isn't an issue, 
would always include the full set of functions. Users on space 
restricted embedded systems could easily eliminate the functions they 
aren't using to minimize the code space for their targets. The size of 
the SQLite shared library or DLL is normally not a concern on 
workstations with ram measured in GB and disks that are on the order of TB.


Custom functions are a great idea, but it would be better to have a 
wider selection of standard functions so that users only needed to 
resort to custom functions in rare cases (or at least less often).


In order to promote this idea, we are very careful to make sure 
that the SQLite file format does not change in ways that are 
not backwards compatible.  Our goal is to make sure that the

information you put into an SQLite database today is still
easily accessible using general-purpose tools after 20 or 30 
years.


Further to this goal, watch for detailed specficiations of the
SQLite file format to appear in 2008.
  


I'm glad to hear that, and look forward to seeing it.

Dennis Cote


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[drh]

"Noah Hart" <[EMAIL PROTECTED]> wrote:
> Why can't new OP codes be simply added to the end, so that the
> serializations will always work?
> 

We do not often add new opcodes.  The usual change is to
alter the meaning and operation of existing opcodes.  We
also delete existing opcodes about as often as we add new
ones.

Furthermore, the opcode numbers are not chosen haphazardly.  
The opcode numbers are in many cases carefully aligned with
token numbers in the parser in order to make the code
generate smaller.  And opcodes that are often used together
within switch statements are grouped together numerically
so that the jump tables used to implement the switch()
statements are smaller - resulting in a smaller executable.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Nicolas Williams]

On Fri, Dec 14, 2007 at 04:20:15PM +, [EMAIL PROTECTED] wrote:
> The EXPLAIN option generates human-readable assembly.  We
> use EXPLAIN extensively when debugging and enhancing.

Yes, but there's no assembler for EXPLAIN output, is there?

Also, the only way to deal with EXPLAIN is to step through its results
-- there's no way to directly insert its output rows into a temporary
table and then use a select using group_concat() to generate a single
string consisting of the VDBE assembly.  It is, however, possible to use
.mode insert and explain to generate INSERT statements that can then be
used to insert the VDBE program into a table, and then one can do more
interesting things (I suppose one could even write an assembler in SQL).

> I should point out that while we work very hard to keep the
> file format for SQLite stable, we make no such effort with
> the VDBE.  The opcodes can and do change significantly between
> point releases.  Hence the serializations generated by one
> version of SQLite can only be interpreted by that exact same
> version of SQLite.

Right.

Nico
-- 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] DeviceSQL

[Noah Hart]

Why can't new OP codes be simply added to the end, so that the
serializations will always work?

Noah 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 14, 2007 8:20 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL
Importance: High

Case in point:  A new opcode has been added for the pending 3.5.4
release.  And this caused many of the other opcodes to be
automatically renumbered.  A serialization created for 3.5.3
has little hope of running on 3.5.4.

--
D. Richard Hipp <[EMAIL PROTECTED]>




CONFIDENTIALITY NOTICE: 
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[drh]

Nicolas Williams <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 14, 2007 at 03:38:17PM +, [EMAIL PROTECTED] wrote:
> > That would be the Serialized Statement Extension, SSE.
> > The SSE provides the programmer with two new APIs:
> 
> Would it be useful to generate human-readable VDBE "assemply"?
> 
> Or, how do you develop parser changes that involve new VDBE code
> patterns?
> 

The EXPLAIN option generates human-readable assembly.  We
use EXPLAIN extensively when debugging and enhancing.

I should point out that while we work very hard to keep the
file format for SQLite stable, we make no such effort with
the VDBE.  The opcodes can and do change significantly between
point releases.  Hence the serializations generated by one
version of SQLite can only be interpreted by that exact same
version of SQLite.

Case in point:  A new opcode has been added for the pending 3.5.4
release.  And this caused many of the other opcodes to be
automatically renumbered.  A serialization created for 3.5.3
has little hope of running on 3.5.4.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Nicolas Williams]

On Fri, Dec 14, 2007 at 10:10:04AM -0600, Nicolas Williams wrote:
> On Fri, Dec 14, 2007 at 03:38:17PM +, [EMAIL PROTECTED] wrote:
> > That would be the Serialized Statement Extension, SSE.
> > The SSE provides the programmer with two new APIs:
> 
> Would it be useful to generate human-readable VDBE "assemply"?

I meant "assembly".

> Or, how do you develop parser changes that involve new VDBE code
> patterns?

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Nicolas Williams]

On Fri, Dec 14, 2007 at 03:38:17PM +, [EMAIL PROTECTED] wrote:
> That would be the Serialized Statement Extension, SSE.
> The SSE provides the programmer with two new APIs:

Would it be useful to generate human-readable VDBE "assemply"?

Or, how do you develop parser changes that involve new VDBE code
patterns?

Just curious,

Nico
-- 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[drh]

Dennis Cote <[EMAIL PROTECTED]> wrote:
> 
> It could be any application that uses a fixed set of predetermined SQL 
> statements to perform its operations. My primary application does 
> exactly that using SQLite with all statements prepared and cached as 
> needed. It runs on a standard PC under Windows. We have no need for 
> executing arbitrary, runtime generated, or user supplied SQL as many 
> other applications do. Every SQL statement that can be executed is known 
> before the application starts.
> 

Your application uses a fixed set of SQL statements now.  But
that set of statements might change in the next release. Or you
might change or modify a table, or add an index.  

A key feature SQLite is that these changes preserve the file
format.  With other systems, when you change the schema the
file format changes with it.

One of the ideas I try to push is SQLite as an Application File 
Format.  The idea is that you put your information in an SQLite 
database file and it is then readable by diverse, general-purpose 
tools, and across multiple releases.  Sure, the schema might
change from one release to the next, but the data is still
easily accessible.

In order to promote this idea, we are very careful to make sure 
that the SQLite file format does not change in ways that are 
not backwards compatible.  Our goal is to make sure that the
information you put into an SQLite database today is still
easily accessible using general-purpose tools after 20 or 30 
years.

Further to this goal, watch for detailed specficiations of the
SQLite file format to appear in 2008.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Shawn Wilsher]

On Dec 14, 2007 10:38 AM,  <[EMAIL PROTECTED]> wrote:
> That would be the Serialized Statement Extension, SSE.
> The SSE provides the programmer with two new APIs:
>
>int sqlite3_serialize(sqlite3_stmt*, void**, int*);
>int sqlite3_deserialize(sqlite3*, void*, int, sqlite3_stmt**);
>
> The first routine takes an SQL statement that was generated by
> sqlite3_prepare() and converts it into a form that can be stored
> on disk or compiled into a program.  The second routine does the
> reverse; it takes the serialization of a statement and converts it
> back into a working SQL statement that can be used just like any
> other statement created by sqlite3_prepare().
>
> You compile SQLite normally on your development workstation, but
> for you embedded target you add -DSQLITE_OMIT_PARSER to leave off
> the parser.  By omitting other optional features (date/time functions,
> views, triggers) you can get the size of the library down to the 70KiB
> range or less.
>
> On a workstation, you can sqlite3_prepare() statements, then hand
> them to sqlite3_serialize().  The results can be hard coded into
> C programs to be manually deserialized later, if you like, though
> that is a lot of work.  A simpler approach is to use the special
> sqlite_statement table:
>
>CREATE TABLE sqlite_statement(
>   id INTEGER PRIMARY KEY,
>   sql TEXT,
>   serial BLOB
>);
>
> A new API is available that will automatically extract and deserialize
> an SQL statement from the sqlite_statement table given its id number:
>
>int sqlite3_fetch_statement(sqlite3*, int id, sqlite3_stmt**);
>
> The idea here is that the SQL statements needed by an application can
> be inserted as plain text into the sqlite_statement table.   For
> example:
>
>INSERT INTO sqlite_statement(sql) VALUES('SELECT * FROM table1');
>
> After many such statements are inserted, they can all be serialized
> as follows:
>
>UPDATE sqlite_statement SET serial = sqlite_serialize(sql,id);
>
> Then the complete database can be moved from the development platform
> over to the embedded device and the embedded device can use the
> sqlite3_fetch_statement() API to extract the statements it needs to
> execute.
>
> To be useful, your precompiled statements will normally contain
> parameters (ex: "INSERT INTO tx VALUES(?,?,?)") and the embedded
> application will using sqlite3_bind_xxx() interfaces to attach
> values to these parameter prior to invoking sqlite3_step().
>
> The SSE has not been kept current with the base SQLite.  But if there
> is interest, we could resurrect it easily enough.

I think that Mozilla may find that useful.  I think it came up about a
month ago with some places code (new bookmark back-end).

Seth, I think it was you and Mano that were talking about this.  Would
this be useful for us?

Cheers,

Shawn

>
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
>
>
> -
>
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
>
>

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[drh]

Dennis Cote <[EMAIL PROTECTED]> wrote:
> 
> > I can imagine that a version of Sqlite which does not include its SQL 
> > compiler and which uses precompiled VDBE code would provide similar 
> > functionality to DeviceSQL, particularly if the Sqlite compiler were 
> > extended to generate VDBE from PL/SQl.  I can imagine that the higher 
> > information density of the VDBE code could deliver the advantage =of a 
> > smaller memory footprint.
> 
> I thought that this already existed as a commercial product that Richard 
> offered, but I can't find any reference to it on the paid support page 
> at http://www.hwaci.com/sw/sqlite/prosupport.html. My recollection was 
> an offline compiler that ran on a PC and generated VDBE code to execute 
> SQL statements, along with source code for a runtime execution engine 
> that would execute those pre-compiled statements. The execution engine 
> could be built for any target, and was much smaller than SQLite because 
> it eliminated the parser and code generator functionality. Does this 
> exist, or was I just imagining it?
> 

That would be the Serialized Statement Extension, SSE.
The SSE provides the programmer with two new APIs:

   int sqlite3_serialize(sqlite3_stmt*, void**, int*);
   int sqlite3_deserialize(sqlite3*, void*, int, sqlite3_stmt**);

The first routine takes an SQL statement that was generated by
sqlite3_prepare() and converts it into a form that can be stored
on disk or compiled into a program.  The second routine does the
reverse; it takes the serialization of a statement and converts it
back into a working SQL statement that can be used just like any
other statement created by sqlite3_prepare().

You compile SQLite normally on your development workstation, but
for you embedded target you add -DSQLITE_OMIT_PARSER to leave off
the parser.  By omitting other optional features (date/time functions,
views, triggers) you can get the size of the library down to the 70KiB
range or less.

On a workstation, you can sqlite3_prepare() statements, then hand
them to sqlite3_serialize().  The results can be hard coded into
C programs to be manually deserialized later, if you like, though
that is a lot of work.  A simpler approach is to use the special
sqlite_statement table:

   CREATE TABLE sqlite_statement(
  id INTEGER PRIMARY KEY,
  sql TEXT,
  serial BLOB
   );

A new API is available that will automatically extract and deserialize
an SQL statement from the sqlite_statement table given its id number:

   int sqlite3_fetch_statement(sqlite3*, int id, sqlite3_stmt**);

The idea here is that the SQL statements needed by an application can
be inserted as plain text into the sqlite_statement table.   For
example:

   INSERT INTO sqlite_statement(sql) VALUES('SELECT * FROM table1');

After many such statements are inserted, they can all be serialized
as follows:

   UPDATE sqlite_statement SET serial = sqlite_serialize(sql,id);

Then the complete database can be moved from the development platform
over to the embedded device and the embedded device can use the
sqlite3_fetch_statement() API to extract the statements it needs to
execute.

To be useful, your precompiled statements will normally contain
parameters (ex: "INSERT INTO tx VALUES(?,?,?)") and the embedded
application will using sqlite3_bind_xxx() interfaces to attach
values to these parameter prior to invoking sqlite3_step().

The SSE has not been kept current with the base SQLite.  But if there
is interest, we could resurrect it easily enough.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Dennis Cote]

John Stanton wrote:


DeviceSQL is not suitable for general purpose SQL processing, unlike 
Sqlite, and should only be compared as an alternative in deeply 
embedded applications so the only useful comparison is one which looks 
like a cell phone, microwave oven or a TV set top box.




The application doesn't necessarily have to look like a microwave. :-)

It could be any application that uses a fixed set of predetermined SQL 
statements to perform its operations. My primary application does 
exactly that using SQLite with all statements prepared and cached as 
needed. It runs on a standard PC under Windows. We have no need for 
executing arbitrary, runtime generated, or user supplied SQL as many 
other applications do. Every SQL statement that can be executed is known 
before the application starts.


I can imagine that a version of Sqlite which does not include its SQL 
compiler and which uses precompiled VDBE code would provide similar 
functionality to DeviceSQL, particularly if the Sqlite compiler were 
extended to generate VDBE from PL/SQl.  I can imagine that the higher 
information density of the VDBE code could deliver the advantage =of a 
smaller memory footprint.


I thought that this already existed as a commercial product that Richard 
offered, but I can't find any reference to it on the paid support page 
at http://www.hwaci.com/sw/sqlite/prosupport.html. My recollection was 
an offline compiler that ran on a PC and generated VDBE code to execute 
SQL statements, along with source code for a runtime execution engine 
that would execute those pre-compiled statements. The execution engine 
could be built for any target, and was much smaller than SQLite because 
it eliminated the parser and code generator functionality. Does this 
exist, or was I just imagining it?


Dennis Cote

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Clay Dowling]

I have to say, this discussion has been very informative, although
probably not in a way that would make mr Weick happy.  I've certainly
learned a lot about encirq that tells me what I need to know about doing
business with them.

Clay

steveweick wrote:
>
> Good  idea... I'll pass it along to the right folks. Meanwhile, if anyone
> has
> further questions or comments, please feel free to write me here (if they
> think the group would be interested) or at [EMAIL PROTECTED]
>
> Steve
>
> I would like to recommend that Encriq create a forum or mailing list of
> their own for those who are interesting in learning more.  For me, what
> might be an interesting product is quickly being overshadowed by this
> thread.
>
>
> --
> View this message in context:
> http://www.nabble.com/DeviceSQL-tp14297970p14329799.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
>
>


-- 
Lazarus Registration
http://www.lazarusid.com/registration.shtml


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[John Stanton]

Testing only finds bugs, it does not guarantee accuracy.  Careful design 
however can establish accuracy, and to verify that methodology requires 
examination of the source code.


James Steward wrote:

steveweick wrote:

Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have 
to be

able to spot bugs through inspection.  While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.
  
I think many would agree that code inspections do find (serious) bugs, 
that may not show up from testing.  I'm sure your company conducts code 
inspection meetings as a part of all code development.  We (the company 
I work for) certainly do.  I know I've seen change logs that read 
something like "Fixed possible buffer overflow in foo..." for open 
source projects here and there as well.



In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.   
That would be bad if they did, I agree.  But all the testing in the 
world won't uncover all the bugs either, in a complex piece of code.  
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf .
"The Ptolemy II system itself began to be widely used, and every use of 
the system exercised this
code. No problems were observed until the code deadlocked on April 26, 
2004, four years later."  And that was after code inspections, 
regression tests and belt and braces programming techniques!

All of that said, I do admire the elegance of the SQLite code.  It makes
entertaining reading.  Unfortunately elegance does not translate into
performance or reliability.
  
Not necessarily, but it often does, and can make for better 
maintainability too.  I've not trawled through to SQLite code myself, so 
couldn't comment.  But it does have quite a few big name users, and an 
active and helpful user forum, which gives me good vibes at least.


Cheerio,
James.

- 


To unsubscribe, send email to [EMAIL PROTECTED]
- 






-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[James Steward]

steveweick wrote:

Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection.  While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.
  
I think many would agree that code inspections do find (serious) bugs, 
that may not show up from testing.  I'm sure your company conducts code 
inspection meetings as a part of all code development.  We (the company 
I work for) certainly do.  I know I've seen change logs that read 
something like "Fixed possible buffer overflow in foo..." for open 
source projects here and there as well.



In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out. 
  
That would be bad if they did, I agree.  But all the testing in the 
world won't uncover all the bugs either, in a complex piece of code.  
See http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf .
"The Ptolemy II system itself began to be widely used, and every use of 
the system exercised this
code. No problems were observed until the code deadlocked on April 26, 
2004, four years later."  And that was after code inspections, 
regression tests and belt and braces programming techniques!

All of that said, I do admire the elegance of the SQLite code.  It makes
entertaining reading.  Unfortunately elegance does not translate into
performance or reliability.
  
Not necessarily, but it often does, and can make for better 
maintainability too.  I've not trawled through to SQLite code myself, so 
couldn't comment.  But it does have quite a few big name users, and an 
active and helpful user forum, which gives me good vibes at least.


Cheerio,
James.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[John Stanton]

I unfortunately missed the Encirq webinar thanks to a project commitment 
but have taken the time to download the Encirq demo and try to make good 
the loss.  It has some user examples in source code which give an idea 
of how it functions, but the information on the product is sparse so it 
was not possible to get an idea of the mechanics of indices, paging etc.


What I saw was a well conceived product to build embedded software.  It 
seems to be a compiler which transforms Encirq's version of PL/SQL into 
C statements which are then compiled into a library of data manipulation 
functions for use in the application.  The demo uses gcc.  Encirq has a 
means of including "storage modules" to handle different forms of 
persistent storage.  DeviceSQL appears to handle transactions and 
rollbacks.  There is no information I could find about ACID functionality.


I shall prepare some benchmarks against Sqlite once I figure out a 
suitable method.  Since DeviceSQl has no SQL compiler the Sqlite will 
need to have prepared statements and binding to provide an apples to 
apples comparison.  The Encirq introductory application example is by 
necessity trivial and small and not suited to a benchmark.


DeviceSQL is not suitable for general purpose SQL processing, unlike 
Sqlite, and should only be compared as an alternative in deeply embedded 
applications so the only useful comparison is one which looks like a 
cell phone, microwave oven or a TV set top box.


I can imagine that a version of Sqlite which does not include its SQL 
compiler and which uses precompiled VDBE code would provide similar 
functionality to DeviceSQL, particularly if the Sqlite compiler were 
extended to generate VDBE from PL/SQl.  I can imagine that the higher 
information density of the VDBE code could deliver the advantage =of a 
smaller memory footprint.


For Steve Weick - I note your very strong resume and would imagine that 
your comprehensive experience would lead you to introduce a less 
secretive policy as to revealing the capabilities of your product.


steveweick wrote:

Good  idea... I'll pass it along to the right folks. Meanwhile, if anyone has
further questions or comments, please feel free to write me here (if they
think the group would be interested) or at [EMAIL PROTECTED]

Steve

I would like to recommend that Encriq create a forum or mailing list of 
their own for those who are interesting in learning more.  For me, what 
might be an interesting product is quickly being overshadowed by this 
thread.






-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[steveweick]

Good  idea... I'll pass it along to the right folks. Meanwhile, if anyone has
further questions or comments, please feel free to write me here (if they
think the group would be interested) or at [EMAIL PROTECTED]

Steve

I would like to recommend that Encriq create a forum or mailing list of 
their own for those who are interesting in learning more.  For me, what 
might be an interesting product is quickly being overshadowed by this 
thread.


-- 
View this message in context: 
http://www.nabble.com/DeviceSQL-tp14297970p14329799.html
Sent from the SQLite mailing list archive at Nabble.com.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] DeviceSQL

[Birt, Jeffrey]

I concur. Quite an interesting marketing strategy; Join you competitors'
mailing lists and trash talk them. LOL

-Original Message-
From: dcharno [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 13, 2007 8:30 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL

I would like to recommend that Encriq create a forum or mailing list of 
their own for those who are interesting in learning more.  For me, what 
might be an interesting product is quickly being overshadowed by this 
thread.


> 
> You raise some interesting points.  There is nothing secret about the
> benchmarks.  We will make the code that was used to run benchmarks
available
> to anyone who wants to see it and verify results. If you want to find
a
> third party to verify, be my guest. The benchmark report goes into
some
> depth on the design and rationale for the benchmark.  Frankly, as much
as I
> like the idea about taking DeviceSQL open source, you don't need to do
so,
> just to verify performance claims.  
> 
> Do you need to read the code to verify reliability as your next few
> sentences seems to imply? For that to be true, the reader would have
to be
> able to spot bugs through inspection.  While that is certainly one way
to
> spot bugs, I seriously doubt that any shop would rely on code
inspection,
> when millions of dollars of potential recall costs are on the line.
> 
> In fact the SQLite marketing does not rely on code inspection as its
> argument for why the code is reliable. Check it out. 
> 
> All of that said, I do admire the elegance of the SQLite code.  It
makes
> entertaining reading.  Unfortunately elegance does not translate into
> performance or reliability.
> 
> Regards,
> 
> Steve
> 
> James Steward-2 wrote:
>> steveweick wrote:
>>> Richard has it right this time.  Today DeviceSQL uses no SQLite
code. One
>>> of
>>> the things we might consider is bolting the SQLite parser/front end
to
>>> our
>>> table engine, in theory to get the both worlds.  Just an idea at the
>>> moment.
>>>   
>> Such an interesting discussion to be following.  I must say though,
it 
>> seems DeviceSQL has opened the door to speculation due to 
>> unsubstantiated claims in advertising, as far as I see it.  IMHO, so 
>> long as there is no independent, unbiased, side by side test results 
>> presented somewhere by some reliable source, there will always be
some 
>> room for "ifs" and "buts" by both sides.
>>
>> Maybe DeviceSQL should go open source, so the public can judge for
them 
>> selves the qualities of the two products.  There would still be money
to 
>> be made from paid support.  Who knows, both parties could benefit,
and 
>> customers too.  At least there'd be a clearer view of the pros and
cons. 
>>
>> There is something to be said for a product being open source, that
is 
>> the code is scrutinized by the world.  Closed shop code can possibly 
>> still be very good, but without seeing it, how would we know?
Reminds 
>> me of a story about a cat: dead or alive, we won't know until we open

>> the box it's in, and prior to that, is it only half dead?
>>
>> One only has to look at the MSDN code examples to see the ugliness of

>> closed source  code development...(sorry Bill)
>>
>> JS.
>>
>>

-
>> To unsubscribe, send email to [EMAIL PROTECTED]
>>

-
>>
>>
>>
> 



-
To unsubscribe, send email to [EMAIL PROTECTED]

-


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[dcharno]

I would like to recommend that Encriq create a forum or mailing list of 
their own for those who are interesting in learning more.  For me, what 
might be an interesting product is quickly being overshadowed by this 
thread.





You raise some interesting points.  There is nothing secret about the
benchmarks.  We will make the code that was used to run benchmarks available
to anyone who wants to see it and verify results. If you want to find a
third party to verify, be my guest. The benchmark report goes into some
depth on the design and rationale for the benchmark.  Frankly, as much as I
like the idea about taking DeviceSQL open source, you don't need to do so,
just to verify performance claims.  


Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection.  While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.

In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out. 


All of that said, I do admire the elegance of the SQLite code.  It makes
entertaining reading.  Unfortunately elegance does not translate into
performance or reliability.

Regards,

Steve

James Steward-2 wrote:

steveweick wrote:

Richard has it right this time.  Today DeviceSQL uses no SQLite code. One
of
the things we might consider is bolting the SQLite parser/front end to
our
table engine, in theory to get the both worlds.  Just an idea at the
moment.
  
Such an interesting discussion to be following.  I must say though, it 
seems DeviceSQL has opened the door to speculation due to 
unsubstantiated claims in advertising, as far as I see it.  IMHO, so 
long as there is no independent, unbiased, side by side test results 
presented somewhere by some reliable source, there will always be some 
room for "ifs" and "buts" by both sides.


Maybe DeviceSQL should go open source, so the public can judge for them 
selves the qualities of the two products.  There would still be money to 
be made from paid support.  Who knows, both parties could benefit, and 
customers too.  At least there'd be a clearer view of the pros and cons. 

There is something to be said for a product being open source, that is 
the code is scrutinized by the world.  Closed shop code can possibly 
still be very good, but without seeing it, how would we know?  Reminds 
me of a story about a cat: dead or alive, we won't know until we open 
the box it's in, and prior to that, is it only half dead?


One only has to look at the MSDN code examples to see the ugliness of 
closed source  code development...(sorry Bill)


JS.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-








-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[steveweick]

Hi James,

You raise some interesting points.  There is nothing secret about the
benchmarks.  We will make the code that was used to run benchmarks available
to anyone who wants to see it and verify results. If you want to find a
third party to verify, be my guest. The benchmark report goes into some
depth on the design and rationale for the benchmark.  Frankly, as much as I
like the idea about taking DeviceSQL open source, you don't need to do so,
just to verify performance claims.  

Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection.  While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.

In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out. 

All of that said, I do admire the elegance of the SQLite code.  It makes
entertaining reading.  Unfortunately elegance does not translate into
performance or reliability.

Regards,

Steve

James Steward-2 wrote:
> 
> steveweick wrote:
>> Richard has it right this time.  Today DeviceSQL uses no SQLite code. One
>> of
>> the things we might consider is bolting the SQLite parser/front end to
>> our
>> table engine, in theory to get the both worlds.  Just an idea at the
>> moment.
>>   
> Such an interesting discussion to be following.  I must say though, it 
> seems DeviceSQL has opened the door to speculation due to 
> unsubstantiated claims in advertising, as far as I see it.  IMHO, so 
> long as there is no independent, unbiased, side by side test results 
> presented somewhere by some reliable source, there will always be some 
> room for "ifs" and "buts" by both sides.
> 
> Maybe DeviceSQL should go open source, so the public can judge for them 
> selves the qualities of the two products.  There would still be money to 
> be made from paid support.  Who knows, both parties could benefit, and 
> customers too.  At least there'd be a clearer view of the pros and cons. 
> 
> There is something to be said for a product being open source, that is 
> the code is scrutinized by the world.  Closed shop code can possibly 
> still be very good, but without seeing it, how would we know?  Reminds 
> me of a story about a cat: dead or alive, we won't know until we open 
> the box it's in, and prior to that, is it only half dead?
> 
> One only has to look at the MSDN code examples to see the ugliness of 
> closed source  code development...(sorry Bill)
> 
> JS.
> 
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DeviceSQL-tp14297970p14328763.html
Sent from the SQLite mailing list archive at Nabble.com.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[James Steward]

steveweick wrote:

Richard has it right this time.  Today DeviceSQL uses no SQLite code. One of
the things we might consider is bolting the SQLite parser/front end to our
table engine, in theory to get the both worlds.  Just an idea at the moment.
  
Such an interesting discussion to be following.  I must say though, it 
seems DeviceSQL has opened the door to speculation due to 
unsubstantiated claims in advertising, as far as I see it.  IMHO, so 
long as there is no independent, unbiased, side by side test results 
presented somewhere by some reliable source, there will always be some 
room for "ifs" and "buts" by both sides.


Maybe DeviceSQL should go open source, so the public can judge for them 
selves the qualities of the two products.  There would still be money to 
be made from paid support.  Who knows, both parties could benefit, and 
customers too.  At least there'd be a clearer view of the pros and cons. 

There is something to be said for a product being open source, that is 
the code is scrutinized by the world.  Closed shop code can possibly 
still be very good, but without seeing it, how would we know?  Reminds 
me of a story about a cat: dead or alive, we won't know until we open 
the box it's in, and prior to that, is it only half dead?


One only has to look at the MSDN code examples to see the ugliness of 
closed source  code development...(sorry Bill)


JS.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[steveweick]

Richard has it right this time.  Today DeviceSQL uses no SQLite code. One of
the things we might consider is bolting the SQLite parser/front end to our
table engine, in theory to get the both worlds.  Just an idea at the moment.

Steve



D. Richard Hipp wrote:
> 
> Joe Wilson <[EMAIL PROTECTED]> wrote:
>> Be careful about speculative comments.
>> 
>> For all anyone knows, said product could use SQLite internally with 
>> a couple of proprietary optimizations here and there that may make it
>> faster in specific cases. 
>> 
>> The sqlite public domain license would allow that sort of thing.
>> 
> 
> Because of the radically different architectures of SQLite
> and DeviceSQL, it seems unlikely that they share a common
> core.  Though, I suppose anything is possible...
> 
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
> 
> 
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DeviceSQL-tp14297970p14327325.html
Sent from the SQLite mailing list archive at Nabble.com.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[steveweick]

As shown another thread, Richard has his facts wrong.  See
http://www.nabble.com/Improving-performance-of-SQLite.-Anyone-heard-of-DeviceSQL--to14280006.html#a14317195

Steve

A. Pagaltzis wrote:
> 
> * John Stanton <[EMAIL PROTECTED]> [2007-12-12 17:55]:
>> In general claims of "20x" or even "5x" imply either serious
>> deficiencies in the compared product or a generous dose of
>> snake oil in the challenger.
> 
> Depends. The outline given by Dr. Hipp about the product’s
> features may the claim quite plausible, because you pay a hefty
> cut in features and reliability in exchange for a very large
> increase in speed; a price that many may well find unacceptable.
> (It is, after all, easy, as they say, to compute the wrong answer
> in constant time.)
> 
> Regards,
> -- 
> Aristotle Pagaltzis // 
> 
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DeviceSQL-tp14297970p14327322.html
Sent from the SQLite mailing list archive at Nabble.com.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[steveweick]

I hope this is not a double post, but this was answered in another thread. 
See 
http://www.nabble.com/Improving-performance-of-SQLite.-Anyone-heard-of-DeviceSQL--to14280006.html#a14317195



D. Richard Hipp wrote:
> 
> John Stanton <[EMAIL PROTECTED]> wrote:
>> I received an email promoting a DeviceSQL web presentation.  It 
>> specifically targets Sqlite and promises 5X performance.
>> 
> 
> If you view their web presentation and/or try out Encirq's
> products, I would be very interested to hear your impressions.
> Even better would be if you could blog about it.
> 
> Encirq has for years been running Google Adsense ads claiming
> to be 20x faster than SQLite.  (Dunno why they have now reduced
> that claim to 5x faster.)  But I have never yet seen an
> independent confirmation of this.  Nor even have I been able
> to find anybody who is actually using DeviceSQL in a product.
> Web searches turn up nothing but marketing literature coming
> directly or indirectly from Encirq.  Some independent analysis
> (regardless of whether it is favorable or unfavorable to SQLite)
> would be appreciated.
> 
> My understanding of DeviceSQL is:
> 
>*  It is NOT transactional.  There is no such thing as ROLLBACK.
>*  If you lose power during a write, your database is toast.
>*  If your database schema changes, you have to recompile
>   your application.
>*  The database file format changes depending on the schema.
>*  DeviceSQL is not a general-purpose database engine.  You
>   compile SQL statements into C code on a development
>   workstation, then compile the C code for your embedded
>   device.
> 
> I can imagine circumstances where the DeviceSQL approach,
> while much less flexible and forgiving than SQLite, might
> be a better way to go, depending on what you are trying to
> do.  But I have not gotten good vibes from Encirq as a 
> company.  And I have no idea how reliable the DeviceSQL 
> product is.  I would really appreciate your thoughts on 
> that subject.
> 
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
> 
> 
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DeviceSQL-tp14297970p14327299.html
Sent from the SQLite mailing list archive at Nabble.com.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] DeviceSQL

[RB Smissaert]

Couldn't find anywhere how much this costs.
Newsgroup search shows nil.
Has anybody downloaded and tried the demo?

RBS

-Original Message-
From: Joe Wilson [mailto:[EMAIL PROTECTED] 
Sent: 12 December 2007 17:10
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DeviceSQL

Be careful about speculative comments.

For all anyone knows, said product could use SQLite internally with 
a couple of proprietary optimizations here and there that may make it
faster in specific cases. 

The sqlite public domain license would allow that sort of thing.


 


Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs


-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[drh]

Joe Wilson <[EMAIL PROTECTED]> wrote:
> Be careful about speculative comments.
> 
> For all anyone knows, said product could use SQLite internally with 
> a couple of proprietary optimizations here and there that may make it
> faster in specific cases. 
> 
> The sqlite public domain license would allow that sort of thing.
> 

Because of the radically different architectures of SQLite
and DeviceSQL, it seems unlikely that they share a common
core.  Though, I suppose anything is possible...

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[Joe Wilson]

Be careful about speculative comments.

For all anyone knows, said product could use SQLite internally with 
a couple of proprietary optimizations here and there that may make it
faster in specific cases. 

The sqlite public domain license would allow that sort of thing.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[John Stanton]

[EMAIL PROTECTED] wrote:

John Stanton <[EMAIL PROTECTED]> wrote:
I received an email promoting a DeviceSQL web presentation.  It 
specifically targets Sqlite and promises 5X performance.




If you view their web presentation and/or try out Encirq's
products, I would be very interested to hear your impressions.
Even better would be if you could blog about it.

Encirq has for years been running Google Adsense ads claiming
to be 20x faster than SQLite.  (Dunno why they have now reduced
that claim to 5x faster.)  But I have never yet seen an
independent confirmation of this.  Nor even have I been able
to find anybody who is actually using DeviceSQL in a product.
Web searches turn up nothing but marketing literature coming
directly or indirectly from Encirq.  Some independent analysis
(regardless of whether it is favorable or unfavorable to SQLite)
would be appreciated.

My understanding of DeviceSQL is:

   *  It is NOT transactional.  There is no such thing as ROLLBACK.
   *  If you lose power during a write, your database is toast.
   *  If your database schema changes, you have to recompile
  your application.
   *  The database file format changes depending on the schema.
   *  DeviceSQL is not a general-purpose database engine.  You
  compile SQL statements into C code on a development
  workstation, then compile the C code for your embedded
  device.

I can imagine circumstances where the DeviceSQL approach,
while much less flexible and forgiving than SQLite, might
be a better way to go, depending on what you are trying to
do.  But I have not gotten good vibes from Encirq as a 
company.  And I have no idea how reliable the DeviceSQL 
product is.  I would really appreciate your thoughts on 
that subject.


--
D. Richard Hipp <[EMAIL PROTECTED]>

Your earlier description of DeviceSQL intrigued me.  In general claims 
of "20x" or even "5x" imply either serious deficiencies in the compared 
product or a generous dose of snake oil in the challenger.  Since we 
know the Sqlite code and use it without encountering serious 
deficiencies, I smell snake, but shall look at the presentation and ask 
some questions if possible and report back.


Like you, I have been unable to uncover any concrete documentation or 
reviews of this product.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DeviceSQL

[drh]

John Stanton <[EMAIL PROTECTED]> wrote:
> I received an email promoting a DeviceSQL web presentation.  It 
> specifically targets Sqlite and promises 5X performance.
> 

If you view their web presentation and/or try out Encirq's
products, I would be very interested to hear your impressions.
Even better would be if you could blog about it.

Encirq has for years been running Google Adsense ads claiming
to be 20x faster than SQLite.  (Dunno why they have now reduced
that claim to 5x faster.)  But I have never yet seen an
independent confirmation of this.  Nor even have I been able
to find anybody who is actually using DeviceSQL in a product.
Web searches turn up nothing but marketing literature coming
directly or indirectly from Encirq.  Some independent analysis
(regardless of whether it is favorable or unfavorable to SQLite)
would be appreciated.

My understanding of DeviceSQL is:

   *  It is NOT transactional.  There is no such thing as ROLLBACK.
   *  If you lose power during a write, your database is toast.
   *  If your database schema changes, you have to recompile
  your application.
   *  The database file format changes depending on the schema.
   *  DeviceSQL is not a general-purpose database engine.  You
  compile SQL statements into C code on a development
  workstation, then compile the C code for your embedded
  device.

I can imagine circumstances where the DeviceSQL approach,
while much less flexible and forgiving than SQLite, might
be a better way to go, depending on what you are trying to
do.  But I have not gotten good vibes from Encirq as a 
company.  And I have no idea how reliable the DeviceSQL 
product is.  I would really appreciate your thoughts on 
that subject.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

[sqlite] DeviceSQL

[John Stanton]

I received an email promoting a DeviceSQL web presentation.  It 
specifically targets Sqlite and promises 5X performance.


For those interested -

DeviceSQL vs. SQLite: Which Gets You the Most Efficient Embedded Database?

DATE: Thursday, December 13th, 2007
TIME:  Noon PST, 3:00 PM EST
DURATION: 50 minutes + Q & A

Register:  
http://seminar2.techonline.com/registration/distrib.cgi?s=1191=1700

Who Should Attend: Software Engineers, Software Architects, Software 
Engineering Managers

Webinar Overview

Reliably processing, searching and managing growing amounts of data is driving 
many embedded developers to use third-party data management software such as 
DeviceSQL or SQLite. However, a critical issue for these technologies is their 
efficiency in terms of performance and memory usage, especially when they’re 
being used to replace hand-coded databases in resource-constrained systems.

While SQLite is widely-known, many users are frustrated by not being able to 
meet stringent performance and/or memory size goals with SQLite, particularly 
in applications with a sub-2 GHz CPU. In this webinar you’ll learn how 
DeviceSQL, a next-generation technology for managing data, provides 5x the 
performance of SQLite while yielding a smaller memory footprint. Also, a 
DeviceSQL user, TV Guide, will share how they were able to meet their 
aggressive design goals for managing electronic program guide (EPG) data. This 
seminar is for engineers who are currently using SQLite or anyone considering 
an embedded database technology.


-
To unsubscribe, send email to [EMAIL PROTECTED]
-