When I began developing Project Shaneera, I had been working in and around the Oracle Database for my entire career and was spoiled by the rich functionality which had grown impressively over the years. Oracle is an expensive option, so I selected MySQL as more cost effective, long term prospect for my application.
I believed that Object Relational Mapping could take place at the database layer.
The logic behind that architecture is this. If we want to minimise network traffic then the more processing that takes place at the database the better. If we are going to communicate in JSON then why not allow the database itself to present and consume JSON.
I find that model appealing for two reasons.
1. The idea of heavy middle tier development in C#, Java or PHP with complex patterns to essentially rebuild the functionality of the database in the middle tier so that we can present SQL to the database fills me with dread.
2. The database currently feels like the most stable part of the architecture. The middle tier technologies have shifted rapidly over the last decade to a point where anything more than two years old “feels” out of date.
The reality of the gulf between Oracle RDBMS and MySQL became apparent almost immediately.
MySQL has plenty of column types that Oracle does not. You can deal with Boolean values, for example, in SQL statements which is great.
The lack of features in the procedural language, such as arrays, default parameter values or the ability to base a variables type on a column has been a source of frustration. Initially, progress has been slower than I expected but there has always been a solution.
Testing is simple for both halves.
There is a very thin PHP layer which completes the text exchange between the two, but does nothing else.
I like the simplicity and clarity of that structure. The database layer is now stable and rarely need any attention.