Re^2: Why use an OO -> SQL mapper module?

One advantage immediately comes to (my) mind: You don't neccesarily need to know SQL

Hmmm. There's no reason not knowing SQL means you have to use an OO mapper. Furthermore, taking Class::DBI as an example, it only generates basic SQL for you. Anything a little bit non-trivial, you need to come up with yourself.

Class::DBI mentions two further advantages in its Introduction section

Eh, the "let's reinvent the wheel" section when it comes to triggers and such? You call that an advantage?

I find that Class::DBI doesn't abstract. Quite the opposite. By mapping tables to classes, it exposes the structure of your database to your application.

Comment on Re^2: Why use an OO -> SQL mapper module?

Replies are listed 'Best First'.
Re^3: Why use an OO -> SQL mapper module? by jethro (Monsignor) on Aug 12, 2011 at 09:18 UTC
There's no reason not knowing SQL means you have to use an OO mapper. No, there is no reason to use OO if you want to abstract, but it is a possibility. And the original question was why should someone substitute SQL with OO. Furthermore, taking Class::DBI as an example, it only generates basic SQL for you. Anything a little bit non-trivial, you need to come up with yourself. If someone doesn't know SQL what are the chances that he will generate non-trivial SQL? I find that Class::DBI doesn't abstract. Quite the opposite. By mapping tables to classes, it exposes the structure of your database to your application. I don't have a problem with calling the abstraction a mapping instead. Note that the author himself says that Class::DBI "provides a simple database to object mapping layer" (emphasis added). The two advantages he mentions (higher oder functions usable without database having a say in it and abstraction of database implementation) still seem to hold even though they might not be implemented to everyones satisfaction	[reply]
Re^4: Why use an OO -> SQL mapper module? by JavaFan (Canon) on Aug 12, 2011 at 17:57 UTC
If someone doesn't know SQL what are the chances that he will generate non-trivial SQL? What are the chances someone not knowing SQL, and need to do something with SQL actually picks up a book, manual page, or a website and learns something? After all, people aren't born with knowledge how to use ORMs either. I'd say that for people who have already displayed the capability to learn how to use a Perl module, those chances are actually quite high. Note that the author himself says that Class::DBI "provides a simple* database to object mapping layer"* Have you actually used Class::DBI? It doesn't map databases to objects. It maps table rows to objects. And I wouldn't object to the notion that Class::DBI maps tables to classes. abstraction of database implementation But that isn't true. Not even for a small part. In its basis, it's "one table", "one class". It's painting the implementation of the database all over your name space. It actually takes a real effort to do worse of an abstraction job than Class::DBI does.	[reply]
Re^5: Why use an OO -> SQL mapper module? by jethro (Monsignor) on Aug 13, 2011 at 00:10 UTC
What are the chances someone not knowing SQL, and need to do something with SQL actually picks up a book... We were talking about non-trivial!! Even intelligent programmers usually don't start with complicated joins when they do their first projects with a database (when they have a choice). My first steps with SQL were pretty basic and could easily have been done within the confines of Class::DBI Have you actually used Class::DBI? It doesn't map databases to objects. It maps table rows to objects. No. And I would be hard pressed to find reasons to use it today when much better alternatives are available abstraction of database implementation But that isn't true. What the author meant was abstraction of the db engine, i.e. it doesn't matter if it was mysql or postgreSQL underneath. Ok, I doubt there are many differences at that level to abstract away, but it is definitely a form of abstraction	[reply]