Re: the relational model of data objects *and* program objects

mountain man wrote:
> The relational model of the data is a very good reference for the
> management of data and its integrity within the RDBMS, but it
> is totally useless for program objects,

Is it? Are you sure? Given the amount of code I see attempting (poorly) to enforce constraints, I'm not sure it has no application in applications.

> Since the emergence of addressable stored procedure objects
> within the RDBMS vendor software at the end of the 1990's
> program objects have lived within the RDBMS.
>
> Given that such an environment exists whereby both data objects
> and program objects are physically stored within the RDBMS
> has anyone seen recently any emergent models that address both
> these objects in a consistent manner?

So let me get this straight - you want a model that addresses the physical? Isn't the putting the cart before the horse, or a drawing of a horse behind the cart?

> Do you think it is important to address the issue that a model
> of both the data objects and the program objects is required?
> [As distinct from a model only of the data side of the picture]

I'm not sure such a model is needed, given the tendency of models to become informal and flabby, but am not averse to the idea.

> NOTE:
> I am aware that there are those here who prefer to classify
> the modern DBMS software of Oracle, IBM and Microsoft
> as non-relational. However I do not share this assertion and
> suggest that these ppls simply ignore the R before the DBMS
> above.

It's not an assertion, it's true by definition (modulo the original use of relation in mathematics). You can easily say "SQL DBMS" and be both correct and non-irritating. Given that this is a theory group, I think definitions are important. Not that they're not important outside theory...

• Eric