Gregor Horvath wrote: > Scott David Daniels schrieb: > >> Using a relational DBMS is most definitely _not_ premature optimization. >> A relational system provides a way to store data so that it is later > > 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. -- http://mail.python.org/mailman/listinfo/python-list
