On 2008-04-07 20:19, Gary Duzan wrote: > In article <[EMAIL PROTECTED]>, > M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> On 2008-04-07 15:30, Greg Lindstrom wrote: >>> SQL is one of the areas I wish I had mastered (much) earlier in my career >> Fully agree :-) >> >> Interesting comments in a time where everyone seems to be obsessed >> with ORMs. > > It seems to me that ORM can work if your database isn't too > complex and it is the only way your database is going to be accessed. > In our case, we have a messy legacy database (lots of tables, > triggers, stored procedures, etc., that nobody really understands) > with multiple processes hitting it, and so our efforts to integrate > Hibernate haven't been terribly smooth. In this environment the > hack seems to be to have Hibernate write to its own tables, then > have stored procedures sync them with the old tables. Not pretty.
While ORMs are nice if you want to get something done quickly, I usually prefer to take the standard database abstraction layer approach: it encapsulated all the database wisdom an application needs, so you don't have to deal with these details at higher levels in the applications, but still allows you to dive right into the full feature set of whatever backend you are using. In addition to having just one place to look for SQL statements, it also provides the needed abstraction to be able to support multiple different backends - by using a common base class and having one subclass per supported database backend. This straight-forward approach makes maintaining support for multiple databases much easier and also allows us to work around problems which you inevitably run into, e.g. missing support for certain features in one backend, data type conversion needs for another, etc. Another problem I found with ORMs is error handling. Since most of the database interaction happens behind the scenes, errors can pop up in situations where you might not expect them in your application. Again, the database abstraction layer provides better control, since that's where you run the queries and deal with the errors. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 09 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list
