Relational Databases vs Object Oriented Databases

    Unfortunately I did not find on the hub enough interesting flocks about object-oriented databases (OOBD). I would like to raise this topic, because Recently, more and more there has been talk of a DLC. However, it will not be possible to put all the information in one article, so I will give you a small overview and my thoughts on this topic to begin with. In this article I will not consider specific solutions based on each of the technologies, but only try to compare the technologies themselves.

    Background


    I have been designing and developing databases for about 6 years. During this time, I developed my vision of how best to approach design, how to choose the system architecture, what features exist when normalizing and denormalizing relational databases, how to optimize certain designs and queries. In the first year of work, I came to the conclusion that I did not want to do the routine of writing the same queries. As a result, I wrote my own stored procedure generator, which, by the structure of the database, generated most of the routine queries (if it is interesting, I can write an article on this topic). Then this generator evolved from year to year, and, in the end, I came to the need to store objects as they are, so as not to bother translating the object model into a relational structure. Those. in fact, I came to generate a certainORM add-in. Of course, you can say that a sufficient number of high-quality ORM add-ins and object-relational databases have already been created that can be successfully used (and I agree with you, but with some reservations). But that didn’t suit me either. And I decided to go further.

    The effect of ORM


    In my humble opinion, the use of ORM add-ons only slows down the development of OOBD. I will try to clarify this rather controversial statement. I do not think that ORM is evil, but it is not absolute good either. ORM technology undoubtedly played (and still plays) an important role in the development of development tools, it showed that a programmer may actually not care about the logic of data storage. However, here, as elsewhere, there are "BUT".

    Using ORM undoubtedly speeds up product development, reduces labor costs and blah blah blah. However, any ORM is a kind of layer that will always work more slowly than direct work (I here by no means urge to transfer all calls to SQL queries to the application - there must be a middle ground). The presence of ORM allows developers to not really think about the work of the DBMS (and they don’t think about it for the most part), which entails, to put it mildly, not quite optimal application operation under load. For optimization, you have to crawl into the layer and configure queries so that they work faster, you have to crawl into the database and reconfigure indexes and tables. Thus, for the application to work optimally, more effort is needed than when there is no ORM.

    However, no one thinks about optimization at the time of writing the first (and often the second, and third) version of the product. For most offices, now the main factor is not quality, but development speed. It is understandable: initially, the customer wants to receive the product as early as possible, spending a minimum of money. And only after some time, when the database is filled with real data, a couple of months will pass, the customer (and the developer too) is surprised to find that the sampling time has almost doubled, with 10-20 users working simultaneously, the DBMS is trying to commit suicide, etc. . etc. The developer is often guided by eastern wisdom: And there, either the donkey will die, or the sultan, or Khoja himself. But, if no one died, then the developer starts looking for bottlenecks, rips 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 carried me away. I hope that I have clearly stated my position on ORM. Let's get back to comparing (or, if you wish, confronting) relational and object-oriented databases.

    Relational DB vs OBOBD


    Despite the enormous popularity of the OOP paradigm in programming, this paradigm is not very popular in database development technology yet. And there are both objective and subjective reasons.
    • Popularity. Many great products have been created for relational databases 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, relatively few serious commercial products have been developed using OOBD; there are few powerful OOSBDs.
    • Query language and its standardization. Back in 1986, the first SQL-86 standard was adopted, which determined the fate of relational databases. After the adoption of the standard, all developers of relational DBMSs were required to follow it. For object-oriented databases, there is no query language standard yet. Now, there is not even a consensus among developers about what this query language should do, not to mention how it should do it.
    • Mathematical apparatus. For relational databases, Edgar Codd once laid the foundation for the mathematical apparatus of relational algebra. This mat. the apparatus explains how the basic operations on relations in the database should be performed, proves their optimality (or it can be seen from it where to optimize). On the other hand, there is no such apparatus for the OOBD, even though work in this area has been ongoing since the 80s. Thus, there are no strict terms in the ODLB, such as the Cartesian product, relation, etc.
    • The problem of data storage and methods. Relational databases store only bare data. What the application will do with them depends on the application. In the OOBD, on the contrary, objects should be stored, and an object is a combination of its properties (object parameters) and methods (object interface). There is also no consensus on how the ODBD should store objects and how the developer should develop and design these objects. This also raises the problem of storing the hierarchy of objects, storing abstract classes, etc.

    Conclusions and Prospects


    In the light of the current situation in the development world, the prospect of serious and popular solutions using OOBD seems rather dubious (but no less desirable) until fundamental issues are resolved (mat machine and query language standard). This, as a developer, makes me a little sad, because I came to the conclusion that the presence of a powerful and convenient DSS 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 for a long time. OOBD all the same will not be able to replace relational databases in full. In some real-world tasks, it is still more convenient and correct to store data not in objects, but in tables.

    Thus, I believe that over time, OOBD will win back from the relational database a piece of the market for commercial systems, but to achieve such a total advantage that relational databases now have no power for them.

    Also popular now: