Maybe I’ll get onto a train of thought here and actually post a couple more things I have drafted along these same lines — my own code, my ORM article, and some neat things ORM-ish systems can actually be great for, such as an in-database, single-query ACL system.

I enjoy my Type 2 (maybe 2.5 because it does have a feature to auto-generate an INSERT/UPDATE) system because it makes more sense for me to code with. It works the way I think. I’ve never tested, but I think it has barely any overhead. But it also only connects to MySQL. I never had to connect to anything else, so I only wrote one back-end. If I were working with a system that I wanted to support several different databases, I’d write the new back-end, and then ship the product with two sets of queries.

You are also not writing code that will have horrible performance if you stick to portable ANSI SQL.

That is not true. In every system I’ve worked with, there are examples of ANSI standard SQL queries — and simple ones at that — which are terribly optimized. This is why I won’t use auto-generated code for anything beyond a one-row select with a simple WHERE clause, and even then only if I know there’s no way it will burn me.

I agree that they help you in the common case, if your common case is those one-row selects. As I mentioned at my previous job, there was about a 4-to-1 ratio of those in one specific system. However, I’ve written other systems where the “common case” is between 100 and 5,000 lines of SQL. I’ve done more systems like that than systems with one-row selects.

As for “you minimize the effort required to port to a different product,” again that’s not a benefit for anything I have ever worked on. Telling my bosses we should make it easy to switch from SQL Server to MySQL if we ever wanted to would have been hilarious. The company ran on SQL Server. They ported from a UNIX system to Windows ten or fifteen years ago, when they probably had 5% of their current codebase, and it took many, many years. To port to anything else now would be completely impossible. That may sound like an overstatement, but if you saw how huge the codebase is, you’d agree. The portability argument in a company like that is completely irrelevant. It’s an enormous undertaking even to upgrade versions of SQL Server and make sure things don’t break. Nobody wants to hear about anything worse than that.

Meaning you still keep interface like mysqli but extend it with goodness needed for your own application. In my case I extend it with profiling logging, debugging, handling slave failure etc. You also can extend it to do lazy connecting if you want to.

Type 2 could be good but in PHP there was no fast uniform access for all databases for years. We’ll see how PDO goes. Also I surely do not care about code working with other databases - there would be many changes needed If I decide to do a switch as I’m actively using MySQL only feature. So I would rather adjust my isolated database access code in this case.

One more good thing about such approach - you can plug it in into third party code very easily, Have got application which uses MySQLi object ? And it gets trivial to make this code go via your abstraction library.

But obviously even if you use a DBAL you can put in some code that is RDBMS specific, or you can hand write some joins even if you use an ORM for those extreme cases. The result is that you get fast performance, fast development time and you minimize the effort required to port to a different product.