Merging Oo And Relational

Topics and discussion related to an attempt to merge the concepts of OO and relational to reduce ImpedenceMismatch? issues.

Difficulties I have found while kicking around solutions:

Relational record structures generally have to be consistent for each "record", while objects don't. However, a "dynamic relational" model can be tried, although no known vendor currently offers one. See MultiParadigmDatabase.
- What does that mean? Class structures have to be consistent for each class.
- In some languages you can willy-nilly add a new method at run-time.
- And?
- HughDarwen and ChrisDate claim that equating records with objects is a fundamentally flawed thing to do; see DateAndDarwensTypeSystem.
Polymorphism generally requires a unique "answer", which seems to conflict with set theory. See SetsAndPolymorphism.
- Polymorphism requires a unique answer to what question?
  - Method lookup
  - What paradigm doesn't? And what does this paradigm do when it gets more than one answer? Sum the answers? Average them? Do half of one method and half of another?
  - Perhaps we can explore some examples under SetsAndPolymorphism.
  - I see no relation between method dispatch and that page. Perhaps you can enlighten me.
  - That's the problem. I can't enlighten. There is no known easy way to reconcile polymorphism and set theory. Perhaps we can play with EmployeeTypes examples where there is part-time dispatching and is-manager dispatching or something.
  - You aren't being clear. What paradigm doesn't resolve a method lookup to a unique method? What does it do instead? I see nothing in relational theory about method lookups, so I don't understand what you're trying to say.
  - I will try to develop better examples
Relational generally dictates using relational algebra for "collection" operations. OO proponents sometimes find this distasteful, prefering "dedicated structures" instead. See DedicatedStructuresVersusRdbms.
- OO proponents are free to use relational tables as just another dedicated structure.
  - Yes, but it often results in a different design philosophy and result, and inconsistency. Relational was created as an attempt to reign in variations in structures and structure access. If you can go outside of these, then DrCodd's effort was most in veign.
  - Yes, it results in a design philosophy that allows designs composed of any dedicated data structure, not just relational tables. But since it allows relational tables they can be used when they are the best solution for the problem at hand.
  - But they are not the best solution often enough to abandon relational-centric design up-front. Generally one has to pick one or the other as the main guiding principle. DemoCracy??
  - One doesn't have to pick one or the other. One can pick both.
  - Mixing kills consistency. Relational provides a standard way to deal with non-trivial data. If you don't use the standard, then you are not really using relational, but rather the mishmash the DrCodd wanted to get rid of.
  - Foolish consistency is the hobgoblin of small minds. Use "the" standard when you need to. Use other standards when you need to. You are still "really" using relational, but you are free to use other data structures as well. DrCodd is not a god.
  - I guess I have a small mind.
    - No. He does not understand that relational algebra is an abstract protocol to deal with collections, it is at the logical level and that the various data structures can be used at the physical level, to implement relations. Exposing a plethora of abstract protocols, as they desire, is defeating completely the purpose of the physical-logical independence, namely isolating application programs and users from changes in implementation details.
    - Well, he wants to be able to swap out even the logical level it seems, which is a tall order. To me it would be like wanting to swap out OO and replace the "implementation" with say FunctionalProgramming without rewriting the code. Either that, he is viewing the database as merely a "persistence" mechanism, which it is not unless you use a limiting subset of it. See DatabasesAreMoreThanJustStorage. Note that I wont claim that relational is objectively better than alternatives beyond consistency and OnceAndOnlyOnce here. If someone can show me consistency without relational for complex structures, I am all eyes. OoLacksConsistencyDiscussion.
Storing behavior (code) in tables tends to conflict with the idea that data should be equally accessable to all application languages. The database would possibly have to favor one specific application language.

This section does not follow very seemlessly from the above, but it is related to MergingOoAndRelational.

Having been a RelationalWeenie for a long time (though I always liked OOP), and now becoming good at OOP, I find myself wishing SQL had certain extenstions to make it a bit easier to integrate with OOP code (and non-OOP code, for that matter) that at the same time don't try to actually make the database ObjectOriented.

Assign names to relationships, and assign names in both directions. For instance, when defining the relationship for a link to a record's Parent, call the relation "Parent" in that direction and "Child" in the reverse direction. Now, we should be able to query, for instance, entity.parent.name or Count(entity.child.name) without having to repeatedly spell out the self-join to get the parent record or child records.
- But there may be multiple children. Nor do I think introducing "path notation" is a good thing. It opens a can of worms. One can write functions/methods to provide similar behavior if needed often.
  - The reason I propose the path syntax is that it provides better encapsulation. The implementation can change, and nothing else has to change with it. Your point about 1-m paths is valid. Either the path syntax should invalid for a 1-m relative, or it should be valid only when specifying an aggregation.
  - I would like to see some use-cases where such would pay off.
The ability to separate relational paths from physical schema. In other words, it should be possible to define a field in a company table called address.city today, then change the schema tomorrow so that address is now a relationship, and city is a column in the related table. Also, using aliases (as described below), it should be possible to replace a field called city with an alias to address.city.
- I agree that "view columns" should be available. Views only at the table level can create messy name-space problems. I don't know why view columns are not more common.
Add very limited, non-TuringComplete types of behavior to records. This could include, for instance, 2-way reversible rules for the mathematical relationship between the values in 2 fields. Changing one causes the other to change appropriately, and changes can cascade.
- Example UseCase?
  - Let's say I have a discount amount, and a discount rate, and I'd like to be able to update one, and have the other updated appropriately. It would be nice if we could define a rule relating "discount amount" and "discount rate" such that "invoice amount" * "discount rate" = "discount amount". Yes, I know there are numeric precision issues, so the rules for handling that must be defined and standardized.
  - It sounds like this is kind of a violation of OnceAndOnlyOnce. The discount amount should perhaps be a calculated (virtual) column rather than one updating the other.
The ability to create aliases to local or related values including fields in the table, fields in related 1-1 and m-1 records, and aggregations of related fields in 1-m records. This differs from using views as abstractions between the application and the table because the joins and aggregations in this case are computed if and only if a given query requests the fields that are aliases to them. The client need not know the implementation.
The ability to make fields and aliases deprecated, so they can be kept around to support legacy code, but make log entries log indicating who is trying to use them.
Moved to ExplicitColumnDiscussion.

CategoryRelationalDatabase