[Tfug] Any SQL gurus out there?

[Bexley Hall]

Hi,

[behind on my email and I see a sh*tload of posts
on this subject -- so my $0.02 no doubt overlaps
other comments...]

--- Jim March <1.jim.march at gmail.com> wrote:

> In general terms, how common would it be to include
> "program code"
> inside an SQL database?  Wouldn't that be
> considered, at a minimum,
> squirrelly?

I read this several different ways -- at least several
different ways that I *know* of  :-/

First, augmenting the RDBMS itself with "added code".
In my case, these are *extremely* application-specific
and unlikely *ever* to find use by other developers.
It's more along the lines of coming up with a
different version of the RDBMS itself (PostgreSQL).
[Sorry, I care not to discuss them as there's a fair
bit of IP involved  :> ]

Second, adding extensions to the RDBMS itself.
I have written code to implement several special
data types to suit the needs of my application in
PostgreSQL.  These can be considered part of the
server itself, I guess (though the distinction between
them and stored procedures is fuzzy).  I think this
is done quite commonly.  Whether the support is
implemented in C (as mine is) or PL/SQL, Java, etc.
is just an efficiency question.  For example, I have
an ISBN implementation that more rigorously parses
input data than the support PostgreSQL (currently)
provides.  It also lets me "cheat" and not store
check digits in the table -- I verify them on entry
and recreate them on queries.

Third, adding "business logic" at a higher level of
abstraction to enforce relationships and have finer
control over the data than the underlying data
types and linkage impose (e.g., forcing times-of-day
to be rounded to the nearest 15 minutes, etc.)

Finally, I actually store "programs" in the database
and retrieve them to build my application on the fly.
The RDBMS becomes a "file system", of sorts (the
device model doesn't export the concept of a file
system to the user so the RDBMS plays that role).

In all but the first case, you can query the RDBMS
to "see" the "algorithms" imposed on the data.  So,
there's no smoke and mirrors involved.  In the last
case, the "code" can be examined via a query so it,
too, remains visible.  I.e. the RDBMS still leaves
everything exposed for the user / querant to dig
through, if so inclined.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com