Re: Resiliency To New Data Requirements

erk wrote:
> dawn wrote:
> > erk wrote:

<snip>
> I meant that it's only in the context of information exchange that
> "semi-structured" has any meaning at all (e.g. someone receives
> something and both don't know and don't care about the type or domain
> of part of it).
>
> > That is why I can't (yet, there is still hope) accept lists
> > only as values for attributes and not known to the model at a lower (or
> > higher) level, for example. cheers! --dawn
>
> You said "sure" above, meaning that you care about functions on a type
> of data - that's all in the definition of a type. Why would you care
> whether the DBMS "cares" about lists as long as you do, and can use
> them?

I don't care about what is happening anywhere "behind the scenes" - anywhere I don't interface with directly (with some exception for tuning and assuming there are no bad side-effects. I care about whatever is in the language / interface to the DBMS from start to finish in the development and ongoing support of software products/solutions.

So this gets to the question about what a data model is. The language, or sub-language, used by developers interfacing with the DBMS is an implementation of a data model, right? With SQL-DBMS's (and I KNOW that SQL is not identical to relational, but it was intended to implement the relational model and does implement a model that sticks to the Information Principle) we are missing features that would help the industry develop and maintain software with a bigger bang for the buck (in my opinion -- I realize that has not been proven, Jan says that people have done tests and know the answer to that question, but I don't have the cash to do those tests nor acces to those who do). Lists are an important missing feature (again, my opinion).

So, fine, lists can be translated out of my view into sets and those sets can be translated into functions and 0's and 1's. That is fine with me (even though I know that translating stuff to hex means debugging might require reading hex dumps). I just don't want to model data in accordance with a relational data model (I know, I know, who gives a flying flick what I want? Theory has no need of user requirements...). The good news is that I don't have to model using the RM. Cheers! --dawn

P.S. I decided to ignore the XML quips for now since I know I could do more research in that area and I tried to stick to opinions in this posting where I think my expertise and knowledge could perhaps be enough to permit me a voice in this forum, maybe, possibly, even though I am not a database theorist, but a practitioner interested in theory. P.P.S. Yes, Data and Reality is an excellent book. Received on Sat Aug 19 2006 - 05:05:47 CEST