Learning curve for new database program with Python?
mal at egenix.com
Wed Apr 9 19:01:51 CEST 2008
On 2008-04-07 20:19, Gary Duzan wrote:
> In article <mailman.2994.1207584753.9267.python-list at python.org>,
> M.-A. Lemburg <mal at egenix.com> 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.
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
More information about the Python-list