chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] A call to arms


From: Peter Bex
Subject: Re: [Chicken-users] A call to arms
Date: Thu, 22 Jan 2009 20:28:50 +0100
User-agent: Mutt/1.4.2.3i

On Thu, Jan 22, 2009 at 07:18:54AM -0500, Andrew Gwozdziewycz wrote:
> 
> > I want to use git as a replacement to the db backend (tracking the  
> > xml).
> 
> I was with you until this. I want a storage backend that just works,  
> be it stored in XML, metakit, Sqlite, MySQL, Postgres, Berkeley DB. But
> the kicker is, I want the same interface to work regardless of the  
> storage engine.

I've been there (in PHP, but still) and I am now convinced that this
cannot work on too big a scale.  There is a big mismatch in
expressiveness of some systems.  For our PHP web app framework, we had
built a system that took in abstract array expressions that encoded
constraints, which were compiled to a SQL query for database storage,
or to a PHP filter expression we could run on an array for session-based
storage.

This worked quite well, but we soon realised that as soon as you
have an expression that's not supported by a storage system, you must
then simulate it in your programming language.  When you combine this
with OR expressions, for example, you will end up doing everything
in the programming language:

Suppose you want regex support:
SELECT * FROM foo WHERE foo.x > 10 OR foo.y ~= /address@hidden/
and the SQL DB does not support regexes.  Then you cannot have the
SQL return everything where foo is > 10, and then grep the result
set. You'd actually have to fetch the entire table and perform your
filtering in the programming language.

Of course, I don't know if this is what you had in mind, but be very
careful when you want to do something like this. If there is a single
thing you can express in your abstract system that you cannot express
in even one storage layer, you're in trouble.  It gets worse when you
consider complex joins, with conditions on both sides of the join.
And one-to-many relations are downright evil.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgpbWxg67JAwW.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]