PHP/MYSQL - How are Database Level Constraints handled in Application

I have looked and seen related questions the general question of handling database constraints withi开发者_开发技巧n the application vs native database constraints, but my question is much more pointed and specific with regards to how one handles native mysql constraints within application logic written in PHP.

In other languages/database wrappers, (ADO.NET for example) you place your database interaction within a try/catch and it throws a proper exception, is this the case with php?

Also, does the use of a strict ORM negate the need for database level constraints?

The great myth of try/catch blocks is that the programmer is going to produce amazingly robust code and will actually be able to recover from a failed database query. But the ability to recover from a db error depends on what kind of error there was in the first place -- if there is a sql syntax error, did that code come from the user typing in a query, or from some subroutine that produces the query? If it came from the code, and not the user, then calling the code again will just produce the same error again, so using a try/catch block is simply doomed from the start, the query isn't going to run, ever. And this is generally the type of code you get from a PHP script running on a web server, you run a query, it fails, you escalate the failure and give up. If, on the other hand, you were writing an interactive application in PHP and you needed to properly handle db errors, like a genetic algorithm that was trying to evolve valid SQL statements through random mutation (a very strange example, but anyway) then you would get some benefit from try/catch blocks.

This applies to database-level constraints as well. If you have some long-running application that needs to gracefully deal with constraint violations, well you would have to build that robustness yourself. But I imagine very few people are using PHP in this way, 99% of php out there is used to dump out webpages, and the various wrappers and ORMs reflect this in their designs. There is a far greater chance that .NET would be used to build the type of free-standing application that requires error recovery logic.

Which then leads back to a variation of the original question, when to use or why ever use database constraints? They are most useful when you have a highly dynamic database structure, where the relationship between tables is not known at compile time, i.e. when new tables are created or modified dropped as part of the application itself. You would want this for a hefty data warehouse, or data mining, or perhaps string theory.

In other languages/database wrappers, (ADO.NET for example) you place your database interaction within a try/catch and it throws a proper exception, is this the case with php?

It does with PDO... and i think Mysqli but i havent used that in a couple years so i could be wrong. However it only throws a PDOException... there arent specific exception types for say 'duplicate key' or 'not null'... you have to parse those from the message/code of the exception.

Also, does the use of a strict ORM negate the need for database level constraints?

I would say no. Generally speaking its better to let the db handle this if it can because youre going to have more overhead if you emulate this with PHP.