Re: Databases as objects

DBMS_Plumber wrote:

> Thomas Gagne wrote:
>
>>Bob, you're misunderstanding me.

First, I understand Thomas just fine. As others here have noted, they understand him just fine too.

Second, it makes little sense for Thomas to address me directly. Having noted Thomas' lack of intellectual honesty, I already added him to my killfile, and I will only see those things others reply to.

Third, by denying his objective reality, Thomas renders himself unlikely to learn much of anything and incapable of understanding his own lack of knowledge.

   I do not want to replace SQLese with
>>OOese.

We understand you want to replace SQL with procedure calls as a proxy for object methods. How exactly is that not OOese?

   I'm suggesting that the wonderful SQL you posted can be made >>into a DB-stored procedure to facilitate reuse,

It was an ad hoc program. It was written to perform a single task one time. While one might need to perform a similar task in 12 month's time, the import schema will very likely change in the interim rendering the stored procedure useless. Whether one keeps the source code in the database or in some other repository, one will need to change it before using it again.

Given that it only took a few moments to write, it will only take a few moments to write the appropriate program again when the time comes. In fact, trying to re-use the program may cause one to overlook subtle differences in next year's import schema, and I suggest it might be better to start from scratch.

  and that it is better
>>for multiple programs to call the procedure than for each to embed the SQL.

One will invoke the program exactly once. Thus, one has no need for multiple invocations of the program from other programs.

>>Are we still in disagreement?

Yes, very much so. I added Thomas to my killfile because he is unlikely to ever understand the disagreement. See here: http://www.apa.org/journals/features/psp7761121.pdf or (oh! the irony!) here: http://gagne.homedns.org/~tgagne/contrib/unskilled.html

> I dunno about Bob, but I disagree. Your suggestion would remove
> perhaps the most powerful feature of a SQL DBMS - dynamic SQL. Most of
> the non-trivial systems I've worked on have supported--to a greater or
> lesser extent--mechanisms whereby users could manipulate the UI to
> generate SQL queries 'on the fly'.

While certainly powerful, I am not sure I would call that the most powerful of the features removed. One loses so many.

> If you want to pull that into a 'stored procedure', feel free to do
> so, but then you're just using the modern SQL-DBMS as a kind of
> tp-monitor or application server, only one that shares an address space
> with the data manager. All of which prompts a gigantic shrug.

I suspect Thomas exemplifies the pitfalls of knowing products without fundamentals.

> If you want to 'think different' about this kind of thing, then
> consider, instead of putting the SQL inside the procedural code, the
> potential of putting the procedural code inside the SQL.
>
> CREATE TABLE MyTable (
> ID SomeIdentifierDomain PRIMARY KEY,
> Data SomeApplicationSpecificDomain NOT NULL,
> Related AnotherIdentifierDomain FOREIGN KEY REFERENCES
> ( AnotherTable )
> );
>
> WITH AnalyticResult ( Label, DisplayData ) AS (
> SELECT A.SomeData,
> SomeAggregate( T.Data )
> FROM MyTable T, AnotherTable A
> WHERE T.Related = A.ID
> AND ComplexDomainSpecificPredicate ( A.MoreData, 'Do Re Me Fa
> Lo Sa Te Do')
> GROUP BY A.SomeData
> )
> SELECT OpenGraphWindow ( R.Label, R.DisplayData, :UI_Handle )
> FROM AnalyticResult R;
>
> But then, you can do this already. No one does, is all.
Received on Sat Dec 23 2006 - 16:58:26 CET