Re: Discovering new relationships

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:0wJHh.1243698$1T2.634148_at_pd7urf2no...
> mountain man wrote:
> > ..
> > We are discussing the change management of databases and their
> > schemas. ...
>
> I'm glad you have made that qualification as just exactly what the cm
> theory that you have in mind isn't very tightly drawn for me at this
moment.
>
> However, I note that in a later post, you accept Walt's reply in its
> entirety and if I understand him, he said that concurrency results are
> part of the theory.

Yes, concurrency results are part of the theory.

However, there is a recurring theme in many of mountain man's other posts, that is only tangentially related to concurrency results.

I can't state it precisely , but it's along the lines of "change management in the schema itself" (as distinct from "change managment in the data content"). Kinda like the difference between CREATE, ALTER, and DROP on the one hand and INSERT, UPDATE, and DELETE on the other. But mountain man's issue is at a different level of abstraction than what I just outlined.

This can be one of the largest issues for "large, shared databases" going forward. On the one hand, you want flexibility, so that requirements that didn't go into the logical model of prior versions can be accommodated. On the other hand you want extreme backward compatibility, so that the longevity of the database can be appropriately exploited. The sweet spot on the trade-off is difficult to find.

I'm sure mountain man can state this better than I can. Received on Thu Mar 08 2007 - 15:18:56 CET