Re: chooses not to generate code at all

Responding to Parker...

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.


Nonetheless, what you're describing here is a "trigger", not a "stored
procedure", according to the standard definitions.

I agree that a trigger is separate from a stored procedure in a DBMS in the same sense that an event is separate from a state action in a state machine. So one could execute the stored procedure independently of the trigger. But that isn't the normal execution paradigm for the DBMS any more than it is for the application using state machines.

So I stand by my original assertion that if there is no trigger for the stored procedure, it isn't an integral part of the DBMS execution. IOW, it is just a procedure that happens to be stored in the DB as data.

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.


Perhaps, although the stored procedure does expose a declarative
interface to the data, as opposed to a procedural interface in an OOPL.
 That is a benefit.

Fine. But that benefit exists outside the execution context of the DBMS if there is no corresponding trigger.

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


Surely not OODBMS's, I don't know of any implementation of an OODBMS
that does not break the relational calculus.  The whole point of an
RDBMS is to expose an interface to the data through the relational
calculus to permit set theoretic operations against the data.  That's
it's strength, what sets it apart.

Note that I was specific about Codd's RDM. Entity, Tuple, and Attribute identity and dependencies are related in the same way in an OODB as they are in an RDB's Table, Row, and Field so they can be normalized in the same way. [At least through 3NF; I haven't kept track of the double digit NFs developed over the past couple of decades. B-)] What differs is the accessing infrastructure, such as indexing by Tuple rather than Entity.

Consider a memory-mapped OODB like ObjectStore. The DBMS data model simply mimics the Class Model, which is normalized to 3NF just like an RDB. The difference lies in the implementation for resolving relationships, which is done the OO way by direct object-level reference rather than through Class indexing by embedded keys. But referential integrity is still ensured by 3NF.

[Note that is not inconsistent with set operations. Some abstract action languages used for OOA modeling in UML (e.g., SMALL) are so set oriented that they do not even have constructs for conventional procedural iteration. So set operations can be used to describe the dynamics in the OOA model and, since the OODB just mimics that model, they should be transferable. In fact, in a memory mapped OODB they are the same operations and any limitations would be due strictly to the limitations of the OOPL in hand, not the data model represented in the OOA Class Model. OTOH, I haven't rooted around in the internals of an OODB engine, so I can't speak for how they actually implement the relations.]

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. 


Well, many things can support that, but what an RDBMS offers is a set
theoretic model of data, that takes it to a higher level than a
procedural interface.

That's fine. But as you say, it is a model of the /data/, not the dynamics of using it. My issue in this thread is that the DBMS should stick to just the data model and leave the business dynamic model to the applications. IOW, don't put cast dynamic business actions into triggered stored procedures that the DBMS executes during its normal data storage activities.

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.


Right, and on that score the OODBMS has been noticeably deficient.

I agree, particularly for memory-mapped OODBs where the dependence is two-way. But that pretty much comes with the territory because in the OO paradigm the relationships are used to capture business rules about collaboration participation, which is a very problem-specific issue.

OTOH, one could argue that the relationships necessarily exist in the problem space already so the OODB is just mapping the data domain the same way an RDB does. It's just that the finer granularity of the OO view results in many more relationships and the applications sharing the OODB data just utilize different subsets of relationships from among those intrinsic in the OODB. B-))


*************
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
    ... >>>DBMS is so that the DBMS engine can execute it when triggered by some ... If there is no trigger, ... Stored procedure is one thing. ... > If the procedure execution is not triggered by DBMS ...
    (comp.object)
  • Re: chooses not to generate code at all
    ... 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, ... favorite database and see what the tools call things. ... If the procedure execution is not triggered by DBMS ...
    (comp.object)
  • Re: chooses not to generate code at all
    ... DBMS is so that the DBMS engine can execute it when triggered by some update activity on the stored data. ... If one stores a procedure but does not provide a trigger then that procedure is not an integral part of the DBMS; it's just stored there, which is exactly what DBs do. ... The trigger for execution is insert/update/delete of data by the DBMS and the invocation is controlled by the DBMS. ... high level control subsystem that expanded into several of classes with ...
    (comp.object)
  • Re: Use all available processors ?
    ... Parallelism of a single query execution in the DBMS. ... Processor Affinity for IO in the OS Kernel. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Data driven people arguments
    ... > whose semantics is not relevant to the DBMS. ... > Contrast that with stored procedures whose execution is triggered by the ... if I keep my storing and retrieving logic seperate from my other ...
    (comp.object)