I asked this question a while back on SO (https://stackoverflow.com/questions/15506040/maximising-the-features-of-php-and-mysql-when-used-together) but it's a recurring topic, so I thought I'd ask in a different way over here.Basically, we are stuck with the infamous php and MySQL combination (for various reasons), and are trying to produce applications which follow best-practice as much as possible. We notice that time and again, we are tightly coupling the application to the database and vice-versa, despite trying to adhere to SOLID principles.One of the main reasons is to maximise the features of a relational database (such as strict datatypes, hierarchical data structures, relationships, enforcing foreign keys, firing triggers, etc.) This means that some of the application logic bleeds over into SQL. However, there are features that other RDBMS's offer which MySQL doesn't (such as CHECK constraint most notably) so, we end up using php to get round those.This means we end up using php for some of things MySQL doesn't do well and we use MySQL to do things which aren't feasible in php.So, even though every text book encourages programmers to keep things loosely coupled, does anyone have any examples of how to overcome limitations you have come across, or examples of other applications that mix the two up in a similar way?
How to maximise the features of MySQL when used with php
php;programming practices;mysql
According to this answer, you can solve the CHECK CONSTRAINT problem in the database layer:https://stackoverflow.com/a/14248038Keep in mind that the best practices for an OOP project assume that your application reside in the oop code, and that the database exists to store data from those objects (through a vendor provided or custom ORM layer).  The expectation is that SQL is used mainly to translate objects into the database for permanent storage, not for application logic.There are also best practices for SQL applications.  Many applications are driven almost entirely by a database, with heavy use of stored procedures, triggers, views and other SQL features which are coupled to that database.  In this type of application, the php code is mainly fetching data and handling user input, handling less of the application logic.Both PHP/MySQL are widely used for rapid development, but neither would be mistaken for the 'head of the class' in best practice support in OOP/SQL respectively.  This sometimes causes the pain you describe when implementing features, as you have to mix the two types of applications mentioned above (which then couples the application together).  If that results in an acceptable application with better business results, it may be worth the tradeoff.In the end, if the application can perform reliably and implement the required features under the current workflow, then the best choice is to save the architecture discussion for the next application.  If this can not be done is a reasonable manner, then consider what type of architecture you wish to have and work to migrate the application.