SQL.NET
"People seemed to like the idea that you can store CLR types inside Yukon.
"I like the idea too, but don't get confused.. this is not turning Yukon into an OO-Database and it's not giving Yukon a way to automatically persist your domain objects (i.e., your Customer or your Order). It will work for complex types that have no meaning when split into its simple components, like the 'Point' type.
"Unless they do things like letting you create indexes by these object's fields, and create integrity relations between them, etc, the way to work with data will still be the old-and-great relational model.
"The Yukon implementation seems to follow Chris Date's Third Manifesto, where he says that in the relational model objects map to domains, not to relations, as we usually do when building our data access layers."
[Andres Aguiar's Weblog]
Interestingly, I was just having this conversation with Mr. Sells:
Chris: There's a huge difference between storing objects as columns in a
relational table and an OOD.
Jesse: I agree. I was just wondering because you seemed so opposed to binding any behavior to your data. As if the data should be just raw integers, doubles, and characters to ensure portability.
"Data in OO databases, on the other hand, are bound to behavior and worthless for anything but the limited set of applications for whom the behavior was paramount and the data an implementation detail. When things change, as they always do, how are you going to get the data out so you can do things different? You're going to dump it to the simplest, most complete, most firmly entrenched data format that the world has every known -- relational data."
Aren't you binding the data to behavior by implementing custom types? ;-) It would be very easy to use this to store things like business objects that you didn't want to map to relational entities, in which case you end up with the same predicament.
Chris: I see what you’re saying. By putting data into columns that are custom to a specific object system and not universally accepted as part of the SQL standard, are you decreasing the value of the data? The answer is “yes,” I believe.
Still of note is the fact that Folwer mentions in his book (Patterns of Enterprise...) that sometimes it is acceptable and even desirable to serialize business objects and put them in a column.
Serialized LOB:
"Object models often contain complicated graphs of small objects. Much of the information in these structures isn't in the objects but in the links between them. Consider storing the organization hierarchy for all your customers. An object model quite naturally shows the composition pattern to represent orga-nizational hierarchies, and you can easily add methods that allow you to get ancestors, siblings, descendents, and other common relationships.
"Not so easy is putting all this into a relational schema. The basic schema is simple - an organization table with a parent foreign key, however, its manipula-tion of the schema requires many joins, which are both slow and awkward.
"Objects don't have to be persisted as table rows related to each other. Another form of persistence is serialization, where a whole graph of objects is written out as a single large object (LOB) in a table this Serialized LOB then becomes a form of memento [Gang of Four]."
10:24:24 AM 
|
