Gregor said:
I did not mean that using a relational DBMS is premature optimization
but not using a ORM because of performance considerations is one .
Whether or not to use an ORM might be a fairly big design decision, and
a part of the entire approach to your data handling. For some kinds of
data and some kinds of applications, it will drastically reduce your
flexibility in how you can conveniently deal with the data.
Object oriented design and programming, is often very helpful, but it's
not the only approach you can take to solving a problem in software, and
I'm not sure it's always the best approach...
Using an ORM means that you are making it much more difficult to use the
full expressiveness of SQL. On the other hand, using the full
expressiveness of SQL might make it much more difficult to use your data
in an object oriented way... You have to weigh the pros and cons
depending on the situation.
I'm sure different ORMs might be more or less limiting on SQL. I suspect
that this depends on how well the designer of the ORM knows SQL. I guess
the problem is that those who are best at SQL and most capable of
writing a non-limiting ORB are fairly good at working without an ORM, so
it's the guys who don't really understand and appreciate the strengths
of SQL that designs the ORMs...
If it turns out that the ORM is a performance problem you can always
tune it afterwards. (probably by the DBMS setup, indexes etc.)
To a large extent, use of ORMs and a proper OO design, means that you
move a lot of logic from the the DB and the SQL layer up to the Python
(or whatever language you use) layer, and there are efficient SQL
solutions you simply can't reach in that way.
As a simple example, the natural way to calculate the averages of an
attribute in a set of object in an OO system is to iterate over the
objects, get the value, add up a sum, count the objects as you iterate
and divide the sum with the count once you were done iterating. It's
very simple and straight forward, and often magnitudes slower than the
corresponding obvious SQL solution.
Its just a layer and therefore the endresult is SQL much the same as the
one you would hand code. (and you still can use direct SQL if you like
with most of them)
That's a joke, right? It might be much the same as *you* would have hand
coded, but perhaps very different from what *I* (and I suspect Scott)
would have coded.
With different approaches to your design, you solve problems in
completely different ways. Different languages lend themselves to
very different design approaches. The distinction between declarative
and imperative languages is pretty big, as is the more concrete ways
to actually work with data in Python and SQL.
SQL is a really stupid language in many ways. It's pretty useless
without a good partner, such as Python, and even considering its limited
perspective as a language for querying and manipulating relational
databases, I think it could have been designed so much better. I can't
see any intelligent reason not to provide the kind of abstractions that
function calls provide for instance. The amount of repetition in SQL
code in large database applications is appalling.
Still, there are applications where it's widely superior to any really
existing alternatives, and it goes far beyond manipulating or fetching
individual records in tables.
In any way you have to bridge the logical gap between the relational and
the object data model in your programm.
Certainly.
So you will end up in building a layer between your persistence code and
your problem and domain specific application code, so what you are
actually doing is writing an ORM.
Well, I wouldn't say it's an ORM unless it tries to be generic in some
way. In many cases, this mapping is fairly trivial. I once used
SQLObject for a whisky tasting database web app, and I think it made
life easier for me than raw SQL would have been, but that was a small
system where it was more important to make development fast than to make
the end product fast and robust.
Not reinventing the wheel every time and using a existing one is IMHO a
better approach.
Well, as usual... That depends... For each project you have to decide
how well different available alternatives fit your actual requirements.
If there's an ORM that fit yours, fine. No such external product would
be able to handle the applications I work with right now. The kind of
"conventional" use of SQL in ORMs simply won't work for our needs for
several reasons.
For us, and ORM simply can't solve the problem. For others, it's
overkill.
As I said, ORMs have their uses, but it seems to me that a reason for
many people to use ORMs is to avoid having to properly understand the
way relational databases work, and that means they will never use the
database really well. I'm pretty certain there are cases where it's
better with an ORM and a mediocre use of a database than no ORM and a
complete mess, but that's not the kind of applications or developers I
like to work with.
