* Jim Penny (jpenny@universal-fasteners.com) [010419 14:10]:

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.

I was looking more for *any* examples I could actually play with. Examples that would be using a real, normalized database (3rd or 4th normalized form) that are a littel more complicated than just a single table.

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.

Agreed, but I merged for my project the insert and update, because they *are* nearly the same, except one has an ID already and the other doesn't.

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.

Yes, delete is separate, and the view is seperate.

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

Yes.

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

I have a problem with a database (like a contact management db) that might have: Accounts, Contacts, phone numbers, addresses, and emails. Each would need either 3 or 4 zsql objects for a total of 15-20. That's a big pain in the ass to manage.

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.

I'm sure that's true.

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.

Natch, delete for example deletes from a main table and an xref table.

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.

Yes, but Keep It Simple also means not having an unmanagable number of objects. If there was a way to organize objects by purpose without loosing the advantage of having them in the same folder or creating an ungodly number of folders, that'd be great. Ciao! -- Computers are useless. They can only give you answers. -- Pablo Picasso The Doctor What: Need I say more? http://docwhat.gerf.org/ docwhat@gerf.org KF6VNC