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