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

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]