Re: chooses not to generate code at all

Responding to JXStern...

The issue is stability. Max's Laws haven't changed in quite awhile.


And who's fault is that? 

The Big Bopper in the Sky?

However, most business rules and policies are not so stable. I don't think any rules or policies that are at risk for needing maintenance (or whose scope of application may change) should be implemented as stored procedures. 


Well, but that's surely too broad.


[At least in the conventional sense where the procedure is triggered by specific database updates.


That would be a "trigger", not a "stored procedure" as such.

The whole point of having a stored procedure as an integral part of the DBMS is so that the DBMS engine can execute it when triggered by some update activity on the stored data. If there is no trigger, then...



In theory one could store code, parametric data, and whatnot in the DBMS that is selectively invoked by external applications. In that case those applications define the scope and context of execution rather than the DBMS' data. So in that case the DBMS is just a storage medium for the procedures and doesn't decide when they should be executed.]


That is exactly what a "stored procedure" is all about.

This is just an arbitrary blob of data and the execution dynamics are external to the DBMS. IOW, it is not an integral part of the DBMS itself.

An RDB is not "an MDA". It is simply a model instance that can be either an Input Model or an Output model under MDA, depending upon context. It happens to instantiate a meta-model, which is reflected in schemas, etc.. That meta-model instantiates a general data model especially tailored to persistence (Table, Tuple, Field). 


I'm not sure that these abstractions are "especially tailored to
persistence".  Certainly "field" is a general concept.

The point here is that SQL is not the only way to access an RDB; it is just one access paradigm. Nor is a conventional RDB the only way to implement Codd's RDM (e.g., OODB's and UML Class Models also honor that model.)

IOW: render unto Caesar the things that are Caesar's and render unto the DBMS the things that are data storage.


No, that's just the mistake so many make today. To a first
approximation, a DBMS is not about data storage, it's about data
modelling, and the fact that some entity is implemented as a table
need not be transparent to users, and indeed for occult internal
reasons, there may be times when a 3NF entity is NOT stored as a
table. Soon as you think it's all about storage,

The DBMS exists to provide persistence for data. Much more important, the value of the RDM is that the data can be stored in a manner that is completely independent of its use. The fact that one can model the RDM in general and a particular DBMS doesn't change the nature of its purpose in life.

That separation of concerns is enormously important to managing complexity. When one starts providing dynamic business behaviors as an integral part of a particular DBMS one is trashing the separation of concerns and bleeding cohesion between the problem solution space and the data storage space.

[Note, BTW, that a UML Class Model is normalized to 3NF just like an RDB schema. But the abstractions may be quite different even though both the application and the RDM are abstracting from the same customer problem space. (They won't be so different that one cannot map unambiguously between them because they /are/ derived from the same problem space.) In addition, the application developer should not care if the data is persisted in an RDB, OODB, flat files, or clay tablets; that sort of thing should be completely transparent to the problem solution.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: chooses not to generate code at all
    ... >context of execution rather than the DBMS' data. ... >In this context relational algebra provides a meta-meta-model. ... >meta-model that provides the specific mappings necessary for the ... >are Caesar's and render unto the DBMS the things that are data storage. ...
    (comp.object)
  • Re: chooses not to generate code at all
    ... > DBMS is so that the DBMS engine can execute it when triggered by some ... >>>context of execution rather than the DBMS' data. ... as opposed to a procedural interface in an OOPL. ... >>>are Caesar's and render unto the DBMS the things that are data storage. ...
    (comp.object)
  • Re: chooses not to generate code at all
    ... >The whole point of having a stored procedure as an integral part of the ... >DBMS is so that the DBMS engine can execute it when triggered by some ... Nor is a conventional RDB the only way to ... >problem space. ...
    (comp.object)