DBMS: abstracting concretize

No, not the next ORM, thank God. I want to talk only about the approach to working with abstract DBMS and the paradoxical effect, when more concretely the data model, we get a greater abstraction of the DBMS.

Today, the traditional approach to the design of tasks, as if automatically implies SQL DBMS. Substituting before the very last layer in the system a gasket with a loud name "DBMS abstraction". And what are we abstracting from? From MySQL, Postgress and other SQL, turned sideways. If you find fault, then this will probably be an “abstraction of SQL”, because there are many other types of DBMS.

Creating the data model of the project, we initially think of tables, joins and unions. We are infected with SQL. It seems so natural that the designers make a certain ideological mistake and it is not considered a bad form, for that is not a shame. I say that the data model, as some independent part of the project, is suddenly divided between two components: a computational model and a repository. Stored procedures somehow transfer the data model a little more to storage, but not entirely. Thus, we get the following negative aspects of this concept:

- inability to use non-SQL DBMS
- the harmony of architecture is broken
- ORM suffer overconsumption
')
What is offered as an alternative? First, we completely place the data model into the computational model. We forget about SQL databases and general purpose tables. Our data model will be independent, objective and based on a specific computational model, will speak in its terms, not in terms of tables. We come up with an interface or API, without worrying at all, in which tables it will be stored there.

When the interface is defined, you can create a driver that connects our model with a specific DBMS. Here it will be a complete abstraction. You can connect any SQL, even though files and even BigTable, which is already on the threshold. And the driver itself will always be perfectly sharpened for a specific type of storage and losses will be minimized.

Thus, abandoning general-purpose relational tables when building a model data, and concentrating on the specific needs of the project, we received the following positive points:

- full abstraction DBMS
- preservation of harmony architecture
- no speed loss on ORM

Naturally, with this approach, there are also some nuances. Under certain requests, an overhead projector may occur. For example, you request a list of products:

$ products-> getAll ()

The driver for this will shove the entire tabica, making a couple of joins, and you really only needed the product ID and its name. I see the solution as follows. I said that we should not care how the data will be stored there. Yes it is, but do not really have to be a complete snob. We understand that in 99% of cases the storage will be some kind of relational. Therefore, help the driver when designing the interface / API. Create an additional method or provide a parameter:

$ products-> getIndex () or $ products-> getAll ('brief')

This is how we create a completely concrete data model with a completely abstract DBMS. Using ORM at the same time loses all meaning. Even using it inside the driver will be questionable, since all its general-purpose object charms are not needed. We already have specific, convenient, well-tailored objects in the model.