[Zope3-dev] Re: [Zope-DB] Relational Databases in Zope 2 and Zope 3

[Charlie Clark]

On 2004-06-28 at 16:47:51 [+0200], Luciano Ramalho <ramalho at hiper.com.br> 
wrote:
> On Monday 28 June 2004 09:12, Charlie Clark wrote:
> > Will definitely want to drop <dtml-sqlgroup>, <dtml-sqltest> and such like
> > as these do not encourage good SQL programming.
> 
> How is it that <dtml-sqlgroup> and <dtml-sqltest> do not encourage good SQL
> programming?
> 
> From my experience these commands allow developers to save countless hours
> creating very error-prone and hard-to-debug procedures for assembling SQL.
> <dtml-sqlgroup> and <dtml-sqltest> on the other hand change this procedural
> chore to high level "declarative"-like programming.
> 
> I can't see how this is bad, but I am always eager to learn and if anyone 
> can
> point me to articles explaining why these very useful commands should be
> dropped, I will look deeper into it.

Well, judging by the traffic on the Zope-DB list since I've been on it 
opinions on this are divided but I think the majority of those in the 
relational world are *strongly* against <dtml-sqltest> and <dtml-sqlgroup>. 
They do not add functionality as they replicate SQL and introduce obscurity 
as a result. While SQL has lots of problems it is important that those using 
it really understand what they are writing *and* reading. If you have to be 
able to understand the resultant rendered SQL you should by definition be 
able to write it in the first place. And then there is the issue of 
maintenance - other people might have to read your code!

That said - it is obvious some people will want to keep <dtml-sql> because 
they are comfortable, happy and productive with it. So ZSQL methods will grow 
some options to suit coding style.

There remains the issue of it would be nice to have some way of controlling 
SQL statements so that code reuse in the sense of string reuse is possible, 
ie. mixing in conditions or joins when appropriate. A TALES/METAL approach to 
this seems to me complimentary to current SQL but this discussion is only 
just beginning.

Charlie