IDIOT! Your Data Model Can't Possibly Work!

>>> Jay Dee: The most resilient designs are those which accurately represent data, not relationships. In that vein, I've found Halpern's ORM approach to be helpful -- although his goal of discovering objects is, I feel, slightly off the mark. .
>> Neo: Would you (or someone) be willing to demonstrate this resiliency starting with ... simple example and then extending a bit further? .
> Bob Badour: Neo, you are so full of shit your eyes must be brown. You are an ignorant who doesn't have a clue what he is talking about. NIAM, nijssen and halpin. They set the reference point for conceptual modelling about 20 years ago. Since that time, I have seen nothing I would consider a groundshaking improvement; although, Jan or Vadim might have a better idea if something significantly changed the state of the art in recent years.

This is so funny! Bob, for half a decade you have been telling me that my data model couldn't possibly work, that I didn't have this or that operator, or this or that predicate, didn't attend this or that college, or have this or that experience; yet NIAM/ORM as explained at http://essentialstrategies.com/publications/modeling/niam.htm has quite a few similarities to mine! Actually mine is more general! Now I had been using my own terminology to describe pretty much the same things but you called me an IDIOT! When I first described objects, the type of object I was referring to is what ORM refers to as objects! But you told me I couldn't use that term since it already meant code+data as defined by object-oriented programming. So I changed from objects to things. And because I don't have a control that can display circles and boxes with line between them, I display the same information in a tree and you railed that I was reinventing the hierarchal data model! I told you it was similar to a network of nodes. You railed that I was reinventing the network data model! But if you look at the diagram on the above NIAM/ORM web page, the network I was referring to is very similar to that formed by the various circles and squares with lines between them! What I have described as types/classes, ORM refers to as domains. When I talked about recursion and that properties and values can themselves have their own properties and values and so on, is what ORM calls "nested fact types". Albeit, there are some differences.

In fact I can use the experimental db to store the data (at least the part that I can understand) in the shown ORM diagram in a normalized and NULL-less manner and doesn't ever require the user to specify a schema, normalize data, or worry about IDs and referential integrity. Is there another tool that does similar? Does that tool store the data in a RMDB? If so, I assert that it won't be as flexible as mine. Would someone (Bob?) be willing to demonstrate it here and compare it with the experimental db? Received on Sat Apr 15 2006 - 03:49:46 CEST