Like Vic, I too have moved away from using ORM frameworks. One of my biggest problems with ORM frameworks is that they become a de-facto language within themselves. Instead of learning how to write proper SQL according to the SQL-99 standard, I now have to learn SQL and the syntax of the ORM. Things only get worse from there when trying to debug problems of performance and correctness.

There are some niche tasks where I still use an ORM despite the costs mentioned by Vic and myself. An ORM is great for creating dynamic queries. As we build more rich front-end web applications, it is very easy to build queries with user specified filters and sorting. Trying to do this manually is time-consuming and often bug prone. I find this setup particularly useful when building administrative pages that are looking at lists of things like users or orders. Performance is not a real big issue here and the queries themselves are usually only joining one or two tables. There is still the risk of a runaway query wreaking havoc on your master database. To combat this scare, I advocate a separate slave database to run queries like this.

Vic mentioned that he puts the SQL directory in the controllers, but I think this is a mistake. Controllers are tying the view to the model and should not contain any other logic. I prefer to keep business logic at the library level and data access logic in the model. The controller can consume library or model classes at will and pass them over to the view for output. This may seem like an extra step that is not needed, but it makes testing much easier. There is also the added benefit of being able to write a service layer or API with very little effort should the need arise.

All in all I think Vic makes a good argument. I think developers need to learn to embrace databases, SQL or NoSQL, instead of trying to abstract them away. Data is often the most important part of the business and it should be treated as such.

Common bad example 1: Use a SELECT statement to check if the key exists and INSERT only if the key is not found.
The main problem with this solution is the glaring race condition. In the time in between the SELECT and INSERT, another session can insert the record. You also have to write extra code into your application to process the SELECT query, which may have to specific for many cases. A big waste of time.

Common bad example 2: Delete the row containing the key to be inserted and then INSERT the data again.
Hopefully this is done in a transaction, but it still is dicey. While this solution requires no extra application code to be written, it will only work for very basic cases. Timestamps, flags and other meta data will be lost with a blind delete. This solution scares me the most.

Both examples 1 and 2 can also be made into stored procedures. Don't be tricked into thinking this is a better solution.

The best solution is to insert the data and, if there is an error, check the error code. This is basically what the MySQL INSERT IGNORE syntax does! PostgreSQL, and most major relational databases, follow the ANSI SQL-92 standard. The SQL-92 standard contains a clear list of error codes that an application can check against. If there is a duplicate key error, the application can handle it accordingly. This does not require an extra query, has no race condition and is easy to check for in the application.

For those wondering, 23505 is the error code for duplicate key errors.

A list of all the SQL error codes can be found here:
http://db.apache.org/derby/docs/10.3/ref/rrefexcept71493.html

Edit: Maggie Nelson talks about her experience with this very same issue from an Oracle users point of view in The Rules of (Software) Engagement.