Comments on: Go On, Convince Me http://third-bit.com/blog/archives/970.html Data is ones and zeroes | Software is ones and zeroes and hard work. Thu, 24 May 2012 15:30:31 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: www.crankycoder.com » Blog Archive » Databases == PAIN http://third-bit.com/blog/archives/970.html#comment-1155 www.crankycoder.com » Blog Archive » Databases == PAIN Thu, 05 Jul 2007 22:42:42 +0000 http://pyre.third-bit.com/blog/archives/970.html#comment-1155 [...] On Greg’s weblog, Alex Krizhevsky writes: I’m still having trouble convincing myself that these things offer a distinct advantage over plain-old SQL, at least when we have to write the object definitions by hand. That’s a pain. [...] [...] On Greg’s weblog, Alex Krizhevsky writes: I’m still having trouble convincing myself that these things offer a distinct advantage over plain-old SQL, at least when we have to write the object definitions by hand. That’s a pain. [...]

]]> By: Lilian Hanna http://third-bit.com/blog/archives/970.html#comment-1154 Lilian Hanna Wed, 13 Jun 2007 15:48:36 +0000 http://pyre.third-bit.com/blog/archives/970.html#comment-1154 Hi, so I won't convince you that ORMs are awesome, I am just going to address some of the issues you mentioned here that made you think otherwise. I've only worked with SQLAlchemy and I heard that it is one of the best ones out there. So, to address your first point, you can load the tables from the db into an object without having to define an object to do that by using autoLoad=True when creating the Table object. The only problem with this is that you have to stick to the names of fields used in the db tables to access the object's attributes. In regards to portability, I think one main advantage of using ORMs is portability. If you had used an ORM from the start, the switch from one DBMS to another is just a change in a few lines of code. I have used SQLAlchemy in the past and didn't really find the need to switch to another ORM, so it's highly unlikely you will need to switch to another ORM which took the most effort in your case. I can not agree with you more on not trusting the SQL generated by ORMs. I don't think it is query efficient. I also hate the fact that you can't express complex queries, which you will have to write! SQLAlchemy gives you the option of executing plain SQL queries (some execute() method) but I would have liked to stick to only one method. An advantage of ORMs is that they make your code more readable and for a developer who is not too experienced with SQL, generating SQL queries is like calling object methods so it relies on familiar concepts. Hi,
so I won’t convince you that ORMs are awesome, I am just going to address some of the issues you mentioned here that made you think otherwise. I’ve only worked with SQLAlchemy and I heard that it is one of the best ones out there.

So, to address your first point, you can load the tables from the db into an object without having to define an object to do that by using autoLoad=True when creating the Table object. The only problem with this is that you have to stick to the names of fields used in the db tables to access the object’s attributes.

In regards to portability, I think one main advantage of using ORMs is portability. If you had used an ORM from the start, the switch from one DBMS to another is just a change in a few lines of code. I have used SQLAlchemy in the past and didn’t really find the need to switch to another ORM, so it’s highly unlikely you will need to switch to another ORM which took the most effort in your case.

I can not agree with you more on not trusting the SQL generated by ORMs. I don’t think it is query efficient. I also hate the fact that you can’t express complex queries, which you will have to write! SQLAlchemy gives you the option of executing plain SQL queries (some execute() method) but I would have liked to stick to only one method.

An advantage of ORMs is that they make your code more readable and for a developer who is not too experienced with SQL, generating SQL queries is like calling object methods so it relies on familiar concepts.

]]> By: David Wolever http://third-bit.com/blog/archives/970.html#comment-1153 David Wolever Wed, 13 Jun 2007 03:28:58 +0000 http://pyre.third-bit.com/blog/archives/970.html#comment-1153 Well, I'll speak from the limited experience that I have: a couple (5 or 6) little PHP scripts that use SQL, three little Alchemy projects and then DrProject. When I think back and compare the ordeal I went through with my first couple PHP/MySQL scripts to the hack jobs that were my first couple Alchemy apps, the clear winner is raw SQL. It doesn't take much time to learn enough SQL to get by, and it usually does about what you expect it to. Compare that with Alchemy, which has a steeper (although not altogether terrible) learning curve and makes you as a programmer feel terrible because you have no idea what on Earth is happening, things just magically work (most of the time). But, from my experience with Drproject, there is one huge advantage that ORMs have over SQL when you're working with a large project: the database is one less thing you have to think about. When I'm coding, I don't want to think about database schemas, table and row names, left joins and select unions. I just want an object with data. I want to know is that a Ticket object has an owner, and that owner is a Person, and if I change the owner, the database will change too. Now, I suppose you could write some methods in the object that let you create the object from the database, so the "end developer" doesn't need to think in SQL... But isn't that what Alchemy does? It also strikes me as a BadThing™ that the code knows about the inner workings of the database... But I can't think of any good examples off the top of my tired head. Maybe ask your dad? Well, I’ll speak from the limited experience that I have: a couple (5 or 6) little PHP scripts that use SQL, three little Alchemy projects and then DrProject.

When I think back and compare the ordeal I went through with my first couple PHP/MySQL scripts to the hack jobs that were my first couple Alchemy apps, the clear winner is raw SQL. It doesn’t take much time to learn enough SQL to get by, and it usually does about what you expect it to.

Compare that with Alchemy, which has a steeper (although not altogether terrible) learning curve and makes you as a programmer feel terrible because you have no idea what on Earth is happening, things just magically work (most of the time).

But, from my experience with Drproject, there is one huge advantage that ORMs have over SQL when you’re working with a large project: the database is one less thing you have to think about.

When I’m coding, I don’t want to think about database schemas, table and row names, left joins and select unions. I just want an object with data. I want to know is that a Ticket object has an owner, and that owner is a Person, and if I change the owner, the database will change too.

Now, I suppose you could write some methods in the object that let you create the object from the database, so the “end developer” doesn’t need to think in SQL… But isn’t that what Alchemy does?

It also strikes me as a BadThing™ that the code knows about the inner workings of the database… But I can’t think of any good examples off the top of my tired head.

Maybe ask your dad?

]]> By: Andrey http://third-bit.com/blog/archives/970.html#comment-1152 Andrey Wed, 13 Jun 2007 02:59:35 +0000 http://pyre.third-bit.com/blog/archives/970.html#comment-1152 1. http://erosson.com/migrate/trac/ 2.0. MySQL vs PostgreSQL, maybe. Try building a compatibility layer between MySQL and SQLite. 2.1. Code reuse. Define your model once, and have all your favourite modules use it and the common codebase for accessing the database... If you're going to say "I could do that anyways by writing a central library", then you're just reinventing what SQLAlchemy provides. 2.2. Plus, it's fun to tell it to join five different tables and having it know exactly what keys to join on. Or better yet, let it figure out on its own that some joins are required in order to get the data you need. 3. engine.echo = True, or get familiar with what each method does and you'll know how it's going to build the query. There's a ton of other reasons, many of which are listed on the front page: http://www.sqlalchemy.org/ 1. http://erosson.com/migrate/trac/
2.0. MySQL vs PostgreSQL, maybe. Try building a compatibility layer between MySQL and SQLite.
2.1. Code reuse. Define your model once, and have all your favourite modules use it and the common codebase for accessing the database… If you’re going to say “I could do that anyways by writing a central library”, then you’re just reinventing what SQLAlchemy provides.
2.2. Plus, it’s fun to tell it to join five different tables and having it know exactly what keys to join on. Or better yet, let it figure out on its own that some joins are required in order to get the data you need.
3. engine.echo = True, or get familiar with what each method does and you’ll know how it’s going to build the query.

There’s a ton of other reasons, many of which are listed on the front page: http://www.sqlalchemy.org/

]]>