Relational databases vs Object-oriented databases
Unfortunately I didn’t find enough interesting packs about object-oriented databases (OODB) on Habré. I would like to raise this topic, because Recently, more and more there is talk about OOBD. However, it’s impossible to put all the information in one article, so for a start I’ll give a small overview and my thoughts on this topic. In this article I will not consider specific solutions based on each of the technologies, but will only try to compare the technologies themselves.
I have been designing and developing databases for about 6 years. During this time I had my own vision of how best to approach the design, how to choose the system architecture, what are the features when normalizing and denormalizing relational databases, how to optimize certain constructions and queries. In the first year of work, I came to the conclusion that I do not want to engage in a routine of writing the same requests. As a result, I wrote my own generator of stored procedures, which, according to the structure of the database, generated most of the routine queries (if I'm interested, I can write an article on this topic). Then this generator evolved from year to year, and as a result, I came to the need to store objects as they are, so as not to bother with the translation of the object model into the relational structure. Those. in fact, I came to generate some ORM add-in. Of course, you can say that you have already created a sufficient number of quality ORM add-ins and object-relational databases that can be successfully used (and I agree with you, but with some reservations). But it did not suit me. And I decided to go further.
In my humble opinion, the use of ORM add-ons only hinders the development of OODD. I will try to explain this rather controversial statement. I do not think that ORM is evil, but it is not absolute good either. The ORM technology undoubtedly played (and still plays) an important role in the development of development tools, it showed that the programmer in fact may not care about the logic of data storage. However, here, as elsewhere there are their "BUT".
Using ORM undoubtedly accelerates product development, reduces labor costs and blah blah blah. However, any ORM is a kind of layer that will always work slower than direct work (I’m not urging to transfer all calls to SQL queries to the application - there must be a happy medium everywhere). The presence of the ORM allows developers to not really think about the work of the DBMS (and they still do not think much of it), which entails, to put it mildly, not quite the optimal operation of the application under load. To optimize, you have to reach into the interlayer and tune the queries so that they start working faster, you have to climb into the database and reconfigure indexes and tables. Thus, for the optimal operation of the application, it is necessary to put more effort than when there is no ORM. As a result, we reduce development costs and speed up the release of the first version of the product, but complicate the optimization process.
')
However, nobody thinks about optimization at the time of writing the first (and often the second and third) versions of the product. For most offices, the main factor now is not the quality, but the speed of development. This is understandable: initially, the customer wants to get the product as early as possible, spending a minimum of money. And only after some time, when the database is filled with real data, it will take a couple of months, the customer (and the developer too) is surprised to find that the sampling time has almost doubled, while 10-20 users are working at the same time, the DBMS tries to commit suicide, etc. . etc. The developer is often guided by Eastern wisdom: And there already either the donkey dies, or the sultan, or Hoxha himself . But if no one is dead, then the developer begins to look for bottlenecks, tears out automatically generated queries from ORM, rewrites them with his hands, rebuilds the indexes in the database tables and spends a lot of time and effort on this and similar optimization.
Something drove me away. I hope, I have quite clearly stated my position on ORM. Let's go back to the comparison (or, if anyone - confrontation) relational and object-oriented databases.
Despite the huge popularity of the OO paradigm in programming, this paradigm is not yet very popular in database technology. And there are both objective and subjective reasons.
In the light of the current situation in the development world, the prospect of the emergence of serious and popular solutions using OODB seems rather doubtful (but no less desirable from this) until fundamental issues are resolved (mat apparatus and query language standard). As a developer, it saddens me a bit, for I have come to the conclusion that the presence of powerful and convenient OOBD is simply necessary for the further qualitative development of database development tools.
As for the prospects of relational databases, I believe that they will live long enough. OOBD still can not replace the relational database in full. In some real-life tasks, it is nevertheless more convenient and proper to store data not in objects, but in tables.
Thus, I believe that over time, OODB will recapture a piece of the commercial systems market from relational databases, but they cannot achieve such a total advantage that relational databases now have.
Prehistory
I have been designing and developing databases for about 6 years. During this time I had my own vision of how best to approach the design, how to choose the system architecture, what are the features when normalizing and denormalizing relational databases, how to optimize certain constructions and queries. In the first year of work, I came to the conclusion that I do not want to engage in a routine of writing the same requests. As a result, I wrote my own generator of stored procedures, which, according to the structure of the database, generated most of the routine queries (if I'm interested, I can write an article on this topic). Then this generator evolved from year to year, and as a result, I came to the need to store objects as they are, so as not to bother with the translation of the object model into the relational structure. Those. in fact, I came to generate some ORM add-in. Of course, you can say that you have already created a sufficient number of quality ORM add-ins and object-relational databases that can be successfully used (and I agree with you, but with some reservations). But it did not suit me. And I decided to go further.
Impact ORM
In my humble opinion, the use of ORM add-ons only hinders the development of OODD. I will try to explain this rather controversial statement. I do not think that ORM is evil, but it is not absolute good either. The ORM technology undoubtedly played (and still plays) an important role in the development of development tools, it showed that the programmer in fact may not care about the logic of data storage. However, here, as elsewhere there are their "BUT".
Using ORM undoubtedly accelerates product development, reduces labor costs and blah blah blah. However, any ORM is a kind of layer that will always work slower than direct work (I’m not urging to transfer all calls to SQL queries to the application - there must be a happy medium everywhere). The presence of the ORM allows developers to not really think about the work of the DBMS (and they still do not think much of it), which entails, to put it mildly, not quite the optimal operation of the application under load. To optimize, you have to reach into the interlayer and tune the queries so that they start working faster, you have to climb into the database and reconfigure indexes and tables. Thus, for the optimal operation of the application, it is necessary to put more effort than when there is no ORM. As a result, we reduce development costs and speed up the release of the first version of the product, but complicate the optimization process.
')
However, nobody thinks about optimization at the time of writing the first (and often the second and third) versions of the product. For most offices, the main factor now is not the quality, but the speed of development. This is understandable: initially, the customer wants to get the product as early as possible, spending a minimum of money. And only after some time, when the database is filled with real data, it will take a couple of months, the customer (and the developer too) is surprised to find that the sampling time has almost doubled, while 10-20 users are working at the same time, the DBMS tries to commit suicide, etc. . etc. The developer is often guided by Eastern wisdom: And there already either the donkey dies, or the sultan, or Hoxha himself . But if no one is dead, then the developer begins to look for bottlenecks, tears out automatically generated queries from ORM, rewrites them with his hands, rebuilds the indexes in the database tables and spends a lot of time and effort on this and similar optimization.
Something drove me away. I hope, I have quite clearly stated my position on ORM. Let's go back to the comparison (or, if anyone - confrontation) relational and object-oriented databases.
Relational DB vs OOBD
Despite the huge popularity of the OO paradigm in programming, this paradigm is not yet very popular in database technology. And there are both objective and subjective reasons.
- Popularity. Under the relational database created a lot of great products that need to be maintained and developed. A lot of money has already been invested in these products and customers are ready to invest more in their development. On the contrary, comparatively few serious commercial products have been developed using OOBD, there are few powerful OODBMS.
- Query language and its standardization. Back in 1986, the first standard SQL-86 was adopted, which determined the entire fate of relational databases. After the adoption of the standard, all developers of relational DBMS were required to follow it. For object-oriented databases, while the standard query language is not. Now among developers, there is not even a common opinion about what this query language should do, not to mention how it should do it.
- Mathematical apparatus. Edgar Codd laid the foundation for the mathematical apparatus of relational algebra for relational databases. This mat. the device explains how the basic operations should be performed on relations in the database, proves their optimality (or it can be seen where to optimize). On the other hand, there is no such device for OODB, even though the work in this field has been going on since the 80s. Thus, there are no strict terms in OOBD, such as Cartesian product, relation, etc.
- The problem of storing data and methods. Only bare data is stored in relational databases. What the application will do with them depends on the application. In OODB, on the contrary, objects should be stored, and an object is a collection of its properties (object parameters) and methods (object interface). There is also no consensus on how OODD should store objects and how the developer should develop and design these objects. Here also arises the problem of storing a hierarchy of objects, storing abstract classes, etc.
Conclusions and perspectives
In the light of the current situation in the development world, the prospect of the emergence of serious and popular solutions using OODB seems rather doubtful (but no less desirable from this) until fundamental issues are resolved (mat apparatus and query language standard). As a developer, it saddens me a bit, for I have come to the conclusion that the presence of powerful and convenient OOBD is simply necessary for the further qualitative development of database development tools.
As for the prospects of relational databases, I believe that they will live long enough. OOBD still can not replace the relational database in full. In some real-life tasks, it is nevertheless more convenient and proper to store data not in objects, but in tables.
Thus, I believe that over time, OODB will recapture a piece of the commercial systems market from relational databases, but they cannot achieve such a total advantage that relational databases now have.
Source: https://habr.com/ru/post/93356/
All Articles