Relational camp and "real" database development

Question

More than a decade has passed since the first publication of Date and Darwen 's Third Manifesto in 1995.

What is the place of the relational school of thought in today's world of databases? Is there any evidence that Manifesto's ideas have changed the core software development and data management practices? Did they stimulate the creation of new data management products? Are these products commercially successful?

Answer 1

I have seen a lot of discussion over the years about how OOD should catch up with relational databases "in the near future"; that the relational model is a way of the past; that inertia from a huge installed base (ehm ... legacy) is what delays progress in OOD. “It's just a matter of time before a“ good enough ”implementation finally comes out and succeeds in overthrowing the RDBMS.”

I am not an expert for any reason; but I thought about it many times, and I came to the conclusion that these views are completely lost.

In most "real world" scenarios, the big deal, the only thing that matters is data strong>.

Programming methods, tools, and languages ​​have changed; technology is evolving. Corporate Voice Response Systems become fury and then disappear behind the shadow of Network. Applications come and go; some are good, some not so much; some are critical, some are just comfortable; some last 3 months, some last 3 decades. But in the end, the information that feeds all these applications is at the heart of the system and must survive the fashion swings. Data remains .

So, the core of the "System" should evolve around one goal: to save and protect data.

Think about it: SQL databases, in particular, give us a standalone (mostly) standardized repository with a long-term verified record and can be accessed at any time with no outdated, essentially functional language! This is a pretty good place to trust for your most valuable component.

Any approach that puts a priority on a software tool, environment or application by storing data in a hidden storage - everything that ties the application technology too closely to the data is likely to fall side of the way.

This is not to say that I believe that everything in the world should go into the SQL table. OOD-like solutions also have a place and great potential. But you need to look for places where the “application” is king, and the “data” are secondary: games, one-time applications and tools, systems that store non-critical data or data that does not have long-term value of the application’s lifespan.

In particular, I believe that systems that have a limited useful life (not more than a few years) are the first candidates for such OOD technologies. On the other hand, when working on something that should one day “transfer” data to his successor, I would be very careful about something other than bona fide RDBMS.

To write it to an audio byte, he never touched the "application"; He always referred to "data."

Answer 2

Object-oriented databases are oxymoron. the more you try to make an OO database, the more you find yourself in the relational world. in my opinion, they are just hype. Please note that ORMs are not OO databases. There are also no data sets. I have already heard this argument, so I say it simply so that everything is clear.

Answer 3

We see how object modeling is suitable for managing our data. We have Linq and NHibernate, which allows us to map data in the database, objects in our code. But. I think we are still far from having a real object-oriented database. I'm not sure we'll ever do that. Although working with “objects” has its advantages, processing data as sets with a relational data model has many advantages.

Answer 4

Until now, the OODBMSs that came out did not seem to be as widespread as some wanted them, and the reason was simple: OODBMSs only take into account the problems of OOP developers, but not everyone else, including database administrators, analysts, MIS specialists, and a huge the number of developers who are not object oriented, but who are instead "data driven."

Thus, a huge amount of corporate data remains in the RDBMS, similar to the fact that a huge amount of corporate data also remains in systems with COBOL / CICS.

As for the facts, you can search for statistics for hours, but you won’t find it. All you find is Oracle vs. MS SQL Server compared to MySQL / PostGre / other statistics on the use of open source RDBMS against each other, and OODBMS, such as db4o, are mostly ignored.

Answer 5

When processing business data, the relational model is firmly rooted and cannot be deleted. This is central and often abused for unacceptable things. People will use (abuse) the relational database as a reliable message queue because - well - they see every problem as a database problem.

The relational model is the basis of many (almost all) commercial products for each business process. It is difficult to find anything that is not fundamentally relational. Indeed, in many cases, products are closely related to the database. Oracle Financials, Microsoft Dynamics Accounting, etc.

For the foreseeable future, relational data warehouses will be the main warehouse for processing business data.

Currently, relational databases are self-evident. Everyone asks “what kind of database engine” so that they can weigh in the discussions of Oracle vs. IBM vs. Microsoft vs. MySQL. No one asks: "What will be the data model? Object or relational?"

ORM will continue to advance. Object-oriented programming will continue to grow, leading to an increase in the number of ORMs. Getting out of this box is difficult - almost impossible - because business IT is focused on stability, not innovation. Their goal is almost always "Keep The Lights On." This means rejecting the changes until it is imposed on them by the seller leaving the business or ceasing to support the product.

Answer 6

I have always dealt with data sets that are too large to seriously consider the classical “object” model of rendering data as a class with data elements containing all the information and methods for accessing / manipulating them.

However, I found a simple compromise model with .NET datasets. Since they are a “self buffer” on disk, they are great for processing pieces of data that may or may not be stored in memory, so I use them for my “collections of objects”.

Then, all classes that contain “business objects” for the application simply have a link to a record in the data set that contains their information, and all methods of the class are simply analyzed from the record set.

It works for queries that return 1 result in a million, and the class model is very easily replicated, since basically all the internal data variables of the class are just fields in the recordset.

Answer 7

No The only obvious change has occurred recently with the advent of cloud computing, when supporters did not necessarily store data in a relationship.