Well put. If Sqlite were turned into a junior Oracle, DB2 or PostgreSQL
then someone else would have to create a new Sqlite to handle the
lightweight embedded RDBMS role!
It is very simple to add functions to Sqlite, and since it is a library
you link into your application there is no reason not to have your own
Sqlite-local library which adds all the functions needed by your
application. Many of the features people want to add to Sqlite are
better added by the addition of a specifically targetted application layer.
Those persons wanting the simplicity of Sqlite and all the functionality
of PostgrSQL might do better to re-assess their goals and save time by
using PostgreSQL and coming to terms the fact that the extra complexity
is the price to pay for the added functionality.
In our applications we have done just that and have the advantage of
simple SQL, excellent performance and small footprint in our distributed
applications. We use PostgreSQL where its enterprise features are
necessary to handle large numbers of concurrent users. We thereby avoid
underkill and overkill.
The add-on functions, and application interfaces are better being
contributed software than to bloat Sqlite distributions and be a boat
anchor on its continued development.
Tom Briggs wrote:
In the case of SQLite, I (arguably) have to use a 3rd party
management
tool, for which my custom functions are no longer available. I'm
curious how others handle this.
A. You don't need or use any custom SQL functionality
B. You don't use a 3rd party SQLite management tool
C. Something else I haven't thought of?
I think that the key point you're missing here is that SQLite is not
intended to be standalone database system like the other products you
mentioned (Access, Oracle, etc.) - it is an embeddable database library.
It happens to have a convenient command line interface that allows it to
be used as a standalone database, but that's just a shell (pun intended)
that allows you to get to the library itself. The 3rd party "front
ends" to which you refer are really application consumers of SQLite
itself - not add-ons to or features of SQLite. In other words: it's a
development tool, not a database.
Now, as for a "power" function: we had exactly the same need when we
first started using SQLite. Our solution: we added it. The source code
is freely available, after all. Adding a new function to the code is
shockingly straightforward; from there you simply compile your version
of the library and use that in your application(s). Quick, simple and
portable, both across platforms and applications using your version of
the library.
-Tom
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
