I think the discussion is always useful but prefer it to be less polemic.
Am 25.08.10 12:43, schrieb Andreas Jung:
> SQL can become *very complicated* - ever tried to understand complex
> SQL queries of other people? Working with a proper database model
> on the Python level is much easier.
When mapping classes to relations, sure. OTOH. I have no problem
understanding properly modelled relational schema. As Chris Date points
out "a relation is an object".
I'm not a big fan of SQL per se - I think it manages to make a travesty
of the declarative approach and makes some things which should be easy
tricky. Things are improving with things like windowing functions.
> Yes, you are moving complexity from
> SQL to Python and ORM configuration can be confusing as well. However
> a descriptive model of a database in Python with its relations is much
> easier to handle than dealing with it on the SQL layer directly.
Depending on how the "mapping" (it's actually the generation of SQL on
the fly) happens this can lead to extremely weird modelling. The SA
modelling of subclasses is weird, incorrect in my view. At Europython
Hannu Krosing showed some stats of direct access over the active record
approach. From what I recall of Trac and Django the iterating over large
sets can indeed present a bottleneck which only a good SQL query can remove.
>> > ORM encourages lazy programming = problems later
>> > down the line.
> Nonsense - using SQLAlchemy for more than four years now in four or five
> larger projects and it is a major win regarding productivity, software
> architecture, implementation and testing.
I think SA has the advantage over some approaches in that it lets you do
all the schema in the database, gives you some control over whether
queries should be lazy or not, etc. and letting you write handcrafted
SQL when necessary (it's a great convenience not to have to write them
for getters and setters).
Nevertheless, any programmer working with a relational database should
have a good understanding of the relational model and the core SQL
Furthermore, in my view any good Python programmer should be prepared to
look at other approaches; indeed, I think this is a core advantage of
Python. The Muldis-D project (which is based on the Tutorial D pseudo
language) and Hannu's proposed DORA both offer significant advantages
over SQL and, therefore, SQL generation.
Professional Python Services directly from the Source
>>> >>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Zope-DB mailing list