At 9:14 PM +0100 1/7/08, Zbigniew Baniewski wrote:
On Mon, Jan 07, 2008 at 10:41:35AM -0800, Ken wrote:
In the spirit of the conversation the OP wants the DB to strip out white
space. I contend that this is the applications responsibility either as
DRH suggested by using proper sql expressions. Or by using a trigger. Or
better yet by implementing inside his application if possible adding code
to strip white space.
I'm not sure, whether did you notice, that I wrote about the same - and my
feature suggestion was: "because it's so common operation, repeated again
and again - perhaps the database server/engine could do it"?
Triggers are another route, but I recommend letting the DB do its job of
storage. [..]
Forgive me for being contrary: you just wrote, that most of core functions
listed on http://www.sqlite.org/lang_expr.html seems to be useless. They
aren't related to "DB's job of storage" at all, anyway.
The job of a DB isn't just storage of your data, but also to ensure
that the data it stores is always conformant to the types and
restrictions or business rules that you tell it applies to the data,
so that the data can be trusted.
It makes a lot of sense for a DBMS to be smart and to do a lot of the
data-centric work itself. However, that doesn't mean that the DBMS
has to have a large laundry-list of built-in functions, but more that
it provides the means for users to define the types and business
rules that it wants the DBMS to enforce for data, and routines for
data processing tasks.
So the DBMS itself can be fairly 'lite', and users get the advantage
of having work done in the DBMS while writing that work themselves.
I believe that SQLite already fulfills this mandate to a large
degree, and if it needs more features, it is to provide better
support for users to define the their own database constructs, not
pre-define every possible thing that a user may want to do. We don't
want something designed like PHP.
For your needs, the best thing SQLite can do is provide support for
you to define constraint checks that the strings it stores don't have
leading/trailing spaces, and provide support for you to write stored
procedure wrappers over your insert/update/etc that strip out
leading/trailing spaces. If this stuff ought to be a pragma, then
SQLite should support users defining their own pragmas, rather than
it having this strip-strings one built-in.
I will also clarify that it is useful for SQLite to have some
built-in functionality beyond letting users write their own, but I
don't see that auto-strip is a good candidate for that list ... not
enough of a case for that being generally useful, or too many cases
for why it would be a mis-feature whose use should not get the
encouragement from it being built-in.
-- Darren Duncan
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------