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

[The Doctor What]

--IiVenqGWf+H9Y6IX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* 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.=20

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. =20

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=20
> 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!

--=20
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

--IiVenqGWf+H9Y6IX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE631qgkJDks3INMZURAjH8AJ9CTSWg4Io2TH71CoI8BsTX2q5IeQCcCzhL
ZVDW7h85zWgWmMXg1U6pMKE=
=DqER
-----END PGP SIGNATURE-----

--IiVenqGWf+H9Y6IX--