At one time, I was in that object, relational, etc. stuff. Some people wanted all that stuff combined into some one, unified thingy. My conclusion: The whole

At one time, I was in that object, relational, etc. stuff. Some people wanted all that stuff combined into some one, unified thingy. My conclusion: The whole was a mess. Better just to leave the separate pieces separate. One of the pieces was, sure, relational data base. Then there was the international work on CMIS/P -- IIRC common management informaiton system/protocol. This work seemed to want to model the world and everything in it, but really the goal was how do define and specify data for real time computer and network system management. This work was object oriented and, thereby, open to a lot of confusion: Really, what the work was talking about was just some data, say, describing a printer. So, there be fields with data -- character strings, numbers, arrays, etc. All it was was just data; that is, there was no associated code; no subroutines or functions to call; no applications programmer interfaces (API). The object part was that the definition of data from/for printer A could draw from, inherit from, the definition from printer B, etc. The next part was something we called Resource Object Data Model (RODM). So, the idea was that in real time management of server farms and networks, there could be several different programs trying to manage different aspects of the work, communicating with the same computer or network node, and causing conflicts. So the idea was to have a system, RODM, to present to all the programs trying to manage a single view of the servers and networks to be managed, a single view that would handle locking, exclusive access, cache data from the servers and networks, etc. So, RODM was a hierarchy, say, something like a file system hierarchy. At the leaves were objects that described parts of the servers or networks. The objects were active in the sense that they could run their own, if you will threads of execution, set timers, respond to timers, send and receive messages with other objects, the servers, the networks, programs doing the management, etc. All the hierarchy and objects were dynamic in the sense, much like in a file system, they could be created, changed, and deleted all during real time operations. RODM had some curious, tricky stuff: Could reserve an address space just for data. An address space for code could jump into another address space for code and execute code there. Etc. One role for RODM was for programs to do system management based on AI (expert systems) to have RODM to talk to as model of the servers and networks being managed. It flopped. I contributed a little: Part of such management is detecting and correcting problems in real time. Some of the problems are ones never seen before. So, I worked up how to detect those problems, with known, adjustable false alarm rate, etc. So, that was to be a much better approach to anomaly and early problem detection than we could expect just from the usually intended uses of expert systems. But, really, as for the OP, it was all too complicated.