Re: One Ring to Bind Them

"Laconic2" <laconic2_at_comcast.net> wrote in message news:c9GdnW9YiKJkSlDd4p2dnA_at_comcast.com...
> Was: In an RDBMS, what does "Data" mean?
>
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:wekzc.25516$Dh6.9215_at_newssvr31.news.prodigy.com...
>
> > 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 Received on Mon Jun 14 2004 - 23:36:10 CEST