[Zope] Re: [Zope-dev] ZSQL and Normalized databases (or why ZSQL sucks)

[Jim Penny]

On Thu, Apr 19, 2001 at 01:00:37PM -0500, The Doctor What wrote:
> * The Doctor What (docwhat@gerf.org) [010419 11:57]:
> > Does any one have an example of ZSQL being used witha normalized
> > database?  Or is ZSQL just useless?
> > 
> > Near as I can tell, between:
> > * Broken type marshalling
> > * Loosing the variable between the form and dtml-if
> > * Inability to handle table.field names for variables
> > * And enough flexibility to work around the above problems
> > 
> I would like to apologize for being particularly pissy.  Things are
> quite as bad as I say up there...
> 
> My third point is only half true.  I can have SQLTEST specify a
> column name (aka a field):
> <dtml-sqltest somevarname column="SQLTABLE.sqlfield" type...>
> 
> I know that the '.' has a special meaning, but there should be ways
> around this if the use wants.
> 
> I still would love some examples.  Do people end up with 4 ZSQL
> objects per thing they manipulate in their database?:
> UPDATE, SELECT, INSERT and DELETE?  Or do they mix them somehow?

I cannot emphasize enough.  Do not try to make all-singing all-dancing
ZSQL methods.  This seems to be something that lots of people want
to do for some reason. 

Observation 1:  SQL syntax is incredibly irregular.  It is almost
impossible to write, in any language, a sinlge statement that can
handle these four options.

Observation 2:  You almost always want fewer arguments to a delete
than to an insert.  You also typically have more worries about
deletes than inserts w.r.t. social issues.  That is, typically
there are more people who you allow to select than you allow
to insert than you allow to update than you allow to delete.
For both control reasons and format reasons you do not want
a single SQL statement to handle all possible operations.

Observation 3:  Simple SQL statements are much easier to debug
than complicated ones.  

Observation 4:  Simple SQL statements are much easier to develop
than complicated ones.

Observation 5:  As far as I can tell, there is very little, if any,
space or performance penalty for using many small ZSQL methods rather
than one complicated one.

So, when should you use the fancier options?  If you need to have
rollback work, you may need to combine several statements into a
single method.  If you have a report that changes behavior depending
on its input, maybe you want to use a complicated ZSQL method to 
grab the data.  E.g.  I have a form that accepts a min and a max
part number and a min and max description (and several other min/max
pairs).  I want to sort depending on the first pair filled in.
This is conveniently done with a complicated ZSQL method.  I have
not yet decided if it is wise to do so.

Rule of thumb:  methods should seldom span more than 2 or 3 screenfuls.
The major exception would be a method with an enormous number of
parameters.  Zope is best used with the KISS principle in mind.
It is better to factor a problem into a largish number of very
simple components than it is to use a small number of very complicated
components.  This is especially true when developing through the web,
where you have smallish text windows and more primitive tools.

Jim Penny
> 
> Ciao!
> 
> 
> -- 
> Who are you going to believe, me or your own eyes?
> 	-- Groucho Marx
> 
> The Doctor What: Need I say more?                http://docwhat.gerf.org/
> docwhat@gerf.org                                                   KF6VNC