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

"erk" <eric.kaun_at_gmail.com> wrote in message news:1113336819.857197.122530_at_g14g2000cwa.googlegroups.com...
> 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.

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

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?

>> 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?

Common physical storage of data and program "objects" hints that there exists potential to define some form of common logical storage. The model would address this commonality of logic, rather than restrict itself to the logic of the data objects alone.

>> 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).

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.

> You can easily say "SQL DBMS" and be both
> correct and non-irritating.

Perhaps that is an option, thanks.

> 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.

Consequently, definitions *do* have some requirement to reflect the outside world, such that both their inner and outer (ie: as viewed from an inter-disciplinary perspective) integrity have an optimum value. (IMO)

Thanks for the response.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Wed Apr 13 2005 - 11:38:21 CEST