[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]
-----------------------------------------------------------------------------
