Re: Entity and Identity

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:NGG9m.37712$PH1.5386_at_edtnps82...

> One contingency that military planners or their political masters have
> often failed to allow for is the enemy that refuses to fight according to
> the official battle plan. Sometimes this is called 'exit strategy'. In
> the metadata thread I was surprised you didn't mention one of Codd's basic
> points - metadata is amenable to the same operators and logical structures
> as data. This feature could be viewed as an exit tactic. In RT, there
> are others, perhaps the most basic is the Information Principle. If there
> really is an "OO-mismatch" it is that data is permanently cast according
> to a single perspective for which there may well be no exit strategy.

I don't get the connection between the enemy's refusal to fight according to the battle plan and what is called an "exit strategy".

As far as the single perspective on data goes, one of the topics in the essay is called "The Dual-Schema problem." It seems to me that this problem, as outlined in the essay, is central to the ongoing battles between OO enthusiasts and RM enthusiasts. My own pattern, during the time I was working with databases, was to adopt the RM (or more precisely the SQL approximation to the RM) for data definition and use procedural code for data processing. The problems I was tackling were relatively simple processing rules applied to richly structured data. A lot of commercial data processing is like that.

The fact that the processing was fairly simple meant that I lost fairly little by coding programs in terms of procedures rather than objects. And, with a few proprietary extensions, SQL works pretty well as a procedural language. So I pretty much worked with one schema and one language. I didn't know it at the time, but I had it easy. It's possible that OO programmers have it much tougher because an object world has a schema, sort of. An OO schema is much more implicit than a database schema. It's the explicitness of the database schema that makes databases so powerful. At the same time, the diffculty of getting a schema right the first time, and the high cost of getting a schema wrong is what makes database work seem so difficult to otherwise competent professionals.

What I'd like to see is a way that an OO programming language could work with data defined according to a relational schema. The big problem seems to be that OO doesn't have a good way of describing sets of objects in such a way that an operation on the set can be resolved down to a series of operations on the elements. That's the big thing that I think the query executor does for me in an SQL environment. Presumably, it would do as much or more for me in a D environment. Received on Wed Jul 22 2009 - 19:54:35 CEST