Re: What does this NULL mean?
Date: Thu, 15 Dec 2005 14:52:45 GMT
Message-ID: <1rfof.116914$Gd6.69825_at_pd7tw3no>
Alexandr Savinov wrote:
> Alfredo Novoa schrieb:
>
>>>> Database design maintenance has nothing in special. >> >> >> >>> Well then neither does the original database design. >>> One is just as critical as the other. >> >> >> >> What I mean is that they don't have significant differences. The >> catalog is a database like any other and we already have excellent >> (theoretical) tools to manage databases.
>
>
> Catalog and (user defined) database belong to different layers. They
> have so big differences that cannot be viewed as one data model. Just
> for example:
> - what is row in catalog can be a dimension (column) or a table in user
> level model.
>
> For example, delete a row from a table in your database catalog. What
> happens then? Probably, a column or a table will be deleted. But it is
> not described anywhere in your model because there is no such a model
> that could handle such dependencies. This behaviour is hard-coded into
> every database system rather than is part of its data model.
Not all of them. I knew of one product that did exactly what Alfredo suggested but the users were so indoctrinated that it had to invent ddl to make them happy even though that wasn't needed. I'd say Alfredo is simply pointing out that if the 'catalog' is modelled in ways similar to an application, then some leverage is obvious, ie., ddl becomes a mere shorthand for 'dml'.
Under the covers, using 'dml' will result in a smaller engine but more importantly one that is less prone to inconsistencies, not just in ordinary behaviour but in security, triggered procedures and so forth.
I suspect many of the current products failed to realize this resulting in all kinds of language oddities and more concepts for users/programmers to learn.
p
>
> Currently there are no appropriate tools for modeling catalogs and other
> types of meta information.
>
>> You are trying to mud a very simple issue for unknown purposes.
>
>
> That is not a simple issue. It is one of the most complex open problems.
> For example, what if I need to create a catalog of catalogs?
>
>>> In that case, out with the trivialised summary of >>> schema evolution. You have the floor. Please outline >>> what Date has said about this issue. >> >> >> >> We can manage the schema applying all the power of the RM on the >> catalog relvars.
>
>
> That would be the same as applying, say OOP, to the problem of
> manipulating data in general and schema in particular.
>
>> A very elegant and powerful way. Isn't it?
>
>
> Using your approach we can apply even more powerful way: manipulating
> directly molecules and atom of the CPU where our data is being
> processed. Indeed, why not? And then, according to you, we do not need
> more complex and sophisticated technologies. All atoms are equal, no
> hierarchies, no complex dependencies, no constraints. Just move atoms
> back and forth and produce right order that corresponds to the new state
> of data.
>
Received on Thu Dec 15 2005 - 15:52:45 CET