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

mountain man wrote:
> Central constraint enforcement should be in the database
> and not in the traditional program objects, this is a "given".

Agreed.

> Assume this practice is adhered to, what other relationships
> exist between the relational model of the data and those
> program objects which routinely manipulate this data?

I would infer that the languages used for the program objects would benefit from relations as first-class entities.

> Common physical storage of data and program "objects"
> hints that there exists potential to define some form of
> common logical storage.

I disagree. Common physical storage hints at nothing that I can imagine useful - surely there are "models" of file systems already, and other storage types as well? How physical do you mean - magnetic fields, bits, bytes, files?

> The model would address this
> commonality of logic, rather than restrict itself to the logic
> of the data objects alone.

Data objects have no logic, though logic can be used to manipulate them.

> > It's not an assertion, it's true by definition (modulo the original
use
> > of relation in mathematics).
>
> A truth-definition is a simply another form of assertion
> in which the degree of confidence is set at a max.
>
> However you care to dress it up,
> it is still an assertion.

So by earlier saying "I don't share the assertion [that SQL DBMSs aren't relational]" you mean to redefine "relational"? Why?

> > Given that this is a theory group, I think
> > definitions are important. Not that they're not important outside
> > theory...
>
> Theory evolves, hopefully in pace with the technology.
> Also, no discipline is insular - an island unto itself.

Agreed, but technological (implementation) advances don't necessarily have any impact on theory. Some do, but usually when the technology advance is the result of a possibly implicit theoretical change.  

• erk