We have a rule which gets anyone who says "it would be easiest to..." is
sent to the sin bin until they learn to way "the best way to do this is
...".
The best way generally turns out to be the easiest, but the easiest
never turns out to be the best.
Tom Briggs wrote:
I'm sure that anything is possible, but I do not think that would be
a practical approach. :)
What seems to "easiest" is relative - I find working directly with
the SQLite codebase very, very easy. But I'm a C guy. The whole Tcl
thing gives me the willies. So I wouldn't generalize things according
to language anyway.
-Tom
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 12:56 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Mathematical 'power' operator?
Maybe a dumb queston, but:
As it looks it is easiest to work with SQLite from Tcl, is it possible
to code in Tcl and call that from VB/VBA?
RBS
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]
--------------------------------------------------------------
---------------
--------------------------------------------------------------
---------------
To unsubscribe, send email to [EMAIL PROTECTED]
--------------------------------------------------------------
---------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
