Re: Sourcing Metadata for Database Independence

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:4116a01e$0$34762$e4fe514c_at_news.xs4all.nl...

> What do you mean with "database independent"?
> My guess would be "vendor independent", but
> last time I assumed that I turned out to be wrong.
> So I'm checking.

My assumption is different from yours. My two cents follow.

Just as there are multiple levels of abstraction, so likewise there are multiple degrees of independence.

A data model that described every relevant data value in terms of attributes, relations, and constraints, might be "vendor independent" but not "database type independent". It might be easier to translate such a model into any "relational" (or SQL) DBMS than to a hierarchical, network or object oriented DBMS.

In the past my favorite model for describing data without favoring one particular database type over another was ERD, which slightly favors a relational model, but really can accomodate many other models as well. ERD has been discussed at length in this forum before.

Dawn's stated interest is the future, rather than the past. Like most people, I see the future through a glass, darkly. The best I can do is to extrapolate the past into the future, with all the pitfalls that this entails. I think that something like ERD or OOA will be useful for decades to come.

I would also recast the original topic from "metadata" to "data description". There are other forms of data description, besides metadata. I don't think it's useful to call all of them "metadata". I would suggest that "computer programs" expressed in a "programming language" combine "data descriptions" with "action prescriptions".

I would suggest that database building scripts combine "data descriptions" with "storage container prescriptions".

I'm not sure, but I think the above is more useful than saying that "code is metadata". Received on Thu Aug 12 2004 - 14:50:42 CEST