Re: Databases as objects

kvnkrkptrck_at_gmail.com wrote:

> Thomas Gagne wrote:
> 

One wonders exactly how Mr. Gagne considers a simple imperative statement involving a single value 'higher-level' than the simplest version of a rich imperative statement involving sets of propositions and first-order logic in all its glory. By choosing the least among data statements to compare against the best among OO statements, Mr. Gagne showed that the best of OO can match the least of SQL--itself the least among decent data languages.

Without even getting into a good data language but sticking with SQL, speculate on the OO equivalent of the following ad hoc program:

INSERT INTO catalog(title, author)

SELECT library.title AS title, guild.membername AS author FROM congress_books book JOIN congress_titles library USING (isbn) JOIN guild_pubs pub USING (isbn)
JOIN guild_members guild ON (guild.member_id = pub.member_id) WHERE library.language = 'en_US'
AND book.publication_date BETWEEN '20060101' AND '20061231' AND book.type = 'book'
AND pub.role IN ( 'author', 'coauthor', 'co-author' ) AND book.isbn != ALL ( SELECT isbn FROM blacklist ) AND NOT EXISTS (
   SELECT 1 FROM catalog cat
   WHERE cat.title = library.title
   AND cat.author = guild.membername
)

UNION SELECT bnb.title AS title, bguild.name AS author FROM brit_natnl_biblio bnb JOIN guild_pubs bpub USING isbn JOIN guild_members bguild ON (guild.member_id = pub.member_id) WHERE bnb.pub_date BETWEEN '20060101' AND '20061231' AND bnb.serial = false
AND bpub.role IN ( 'author', 'coauthor', 'co-author' ) AND bnb.isbn != ALL ( SELECT isbn FROM blacklist ) AND NOT EXISTS (
   SELECT 1 FROM catalog c
   WHERE c.title = bnb.title
   AND c.author = bguild.membername
)
;

>>Additionally, I can ask the database to give me a list of its procedures
>>(its interface), but without them all I have is its tables. True, I can
>>tell a lot from the tables and a nice diagram, but I can tell a lot more
>>from a list of procedures and their arguments.

A database is a set of facts or propositions. Set algebra and predicate calculus are the interfaces to sets and propositions. That a dbms provides a facility to create, catalog and run programs as data in no way alters the interface to the database.

>>That list of procedures is the interface I'm talking about. After
>>populating a database with tables, views, and triggers, why keep talking
>>to it using SQL when I can improve my application's interface to it by
>>creating a domain-aware interface with intention revealing named procedures?

Why indeed. Because the intelligent and informed among us consider your so-called 'improvement' perverse. After representing our data as relations with minimal encumbrances and maximal data management facilities, we would have to be incredibly stupid to cripple the dbms behind some retardate procedure names.

One would have to suffer a cognitive deficit even to prefer the 'list' of procedures over a relation.

[additional nonsense snipped]

> I introduced myself to this group with a little parody
> http://groups.google.com/group/comp.databases.theory/tree/browse_frm/thread/16f8e2a48bf7cdee/c6afb5776e727eca?rnum=11&q=kvnkrkptrck&_done=%2Fgroup%2Fcomp.databases.theory%2Fbrowse_frm%2Fthread%2F16f8e2a48bf7cdee%2F5a41db9357aef1b7%3Flnk%3Dst%26q%3Dkvnkrkptrck%26rnum%3D3%26#doc_d0674565740f9e99
> At the time, I had a hard time understanding how certain members of CDT
> failed to see right through it.  In my mind, it was utterly transparent
> baloney - how could it possibly be mistaken for anything but parody?
> 
> Having read this response, I feel obliged to offer Bob Badour and other
> misled CDT contributors a second apology.

Thank you, Kevin. I appreciate your apology, and I long ago forgave your parody. If you feel yourself compelled to further acts of contrition, please choose a small excerpt of nonsense to avoid subjecting the rest of us to the full brunt of the nauseating tedium. Received on Fri Dec 22 2006 - 17:45:38 CET