Re: One Ring to Bind Them

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 15 Jun 2004 03:08:43 +0200
Message-ID: <40ce4c14$0$559$e4fe514c@news.xs4all.nl>

Dawn M. Wolthuis wrote:
> Laconic2 wrote:

>>Eric Kaun wrote:
>>>This is, more than anything, the philosophical divide 
>>>between relational and Pick folks. The more rules,
>>>the more they should be kept OUT of the
>>>application code. "Application" means just that: 
>>>a judicious application.
>>>Of what? Rules. Application != definition, 
>>>just as implementation != specification.
>>
>>It isn't just the Pick folks.  The OO folks 
>>also feel that the business rules belong encapsulated
>>inside the objects that "really know what's going on",
>>as opposed to formalized as metadata and shared
>>the same way data is shared.

>
> Although then "they" (or is that "we"?) start spec'ing things as parms,
> perhaps pulled into the OO code by way of xml documents. You can send
> inputs to pre-existing functions and expect outputs (declarative) and/or
> write functions along with the inputs and outputs (procedural). Any way you
> cut it, there are functions that get executed. Those can be written by the
> Oracle corporation so that if you decouple your assets from the products of
> that company you have less than an entire solution, or you can write the
> functions in a language that doesn't give you quite the same ties to a
> single corporation (such as Java -- and of course we could then argue the
> merits of the Java approach, which doesn't interest me so much as discussing
> the merits of the Oracle approach). You we could store rules/constraints
> as data in the database -- declarative -- and then write functions for that
> part of the application rather than having the database provide those --
> procedural.
>

>>In the days when databases were being spread to the old
>>COBOL and files gang,  this divide was called the
>>difference between "process centric" and
>>"data centric"  views of the world.  
>>I think it's really the same divide, over and over again.

>
> yup, definitely
>

>>It even happens within the RDBMS vendors.
>>I've been watching SQL gradually evolve from 
>>a bad answer to the requirement for a "universal data
>>sublanguange" into a bad programming language, in its own right.

>
> So, how should we fix the situation or is
> declarative vs procedural a matter
> of taste? --dawn

Anybody running an operation with a large shared databank, in practice, has had to bridge this gap. I haven't seen it done in theory yet, though.

Can we fix it? (in theory, that is) -- I am positive we can. But it will take a lot of unlearning.
"They" and "We" does not help. Received on Mon Jun 14 2004 - 20:08:43 CDT