Re: Data driven people arguments

In comp.object, you wrote:
> Responding to Scottf3095...
>
>> This returns us to the question of why can't (or wouldn't you want to)
>> persist behavior in a database? Why shouldn't we have a program that
>> does nothing more that check the database for the code to exectute?
>
> Where one physically stores the application between executions doesn't
> really matter. ...

ok.

> ... If it is stored in the DB, it is just a text blob
> (conceivably object blob) whose semantics is not relevant to the DBMS.

ok

> Creating the application is still a quite separate activity from storing
> it. Similarly, invoking the code is a decision that is handled outside
> the scope of the DBMS. So the separation of concerns between behavior
> and data is preserved even though the behavior may be physically stored
> in the DB.
>

ok...seperation of concerns is important, and storage location is
irrelavant.
got it.

> Contrast that with stored procedures whose execution is triggered by the
> DBMS itself when certain data updates are performed. Then the execution
> of the behavior is an extension of the DBMS behaviors. More important,
> the business rules and policies that determine the triggering have been
> incorporated in the DBMS itself. That trashes the separation of concerns.

In my database (MSSql) stored procedures can be executed independent of
updates.

So, if I keep my storing and retrieving logic seperate from my other
logic...and all logical functions should be seperated anyway....is it
actually necessary to have the business logic in a totally different
environment (i.e. another programming environment like java or vb) to
maintain this seperation of concerns you speak of?

-------------------------------------------------
Panton in temperantia , comprehendo temperantia.
-unknown
-------------------------------------------------

.

Relevant Pages

  • Re: Business objects, subset of collection
    ... from invoice i join payment p on i.invoiceid=p.invoiceid ... The extraction of the data from the DBMS is quite peripheral to that and would be isolated from the rest of the problem solution by encapsulation in a subsystem that hides the DBMS mechanisms. ... TPC implementations rely heavily on stored procedures. ...
    (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: choices regarding where to place code - in the database or middle tier
    ... Sure, the DBMS is a good place for simple referential integrity constraints, ... to 4 separately-running-but-pipelined stored procedures, ... A typical user would enact a 100 or so business functions per day. ... own stored procedures' by storing the SQL for every business query in the DBMS ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middle tier
    ... Sure, the DBMS is a good place for simple referential integrity constraints, ... to 4 separately-running-but-pipelined stored procedures, ... A typical user would enact a 100 or so business functions per day. ... own stored procedures' by storing the SQL for every business query in the DBMS ...
    (comp.lang.java.programmer)
  • 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)