RE: Useful Oracle books

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 27 May 2004 22:29:52 -0500

...I had a similar experience after listening for an hour to Lex de Haan.

Truly.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 6/22 Pittsburgh, 7/20 Cleveland, 8/10 Boston
- SQL Optimization 101: 5/24 San Diego, 6/14 Chicago, 6/28 Denver
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Mogens Nørgaard
Sent: Thursday, May 27, 2004 7:22 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Useful Oracle books

People that go and listen to Chris Date usually come back with a fresh 
look of the world. My old friend Mogens Egan recently saw Date in London 
and told everybody who cared to listen that Date had given him back his 
interest for relational databases.

Mogens

Michael Milligan wrote:

> Anthony,
> 
> Excellent remarks. However, you seem to pitting theory against
practicality
> in a way that does not allow them to coexist. As Date would say, "Theory
is
> practical!" That is actually one of his chapter names. Your example of
> preventing duplicates is a great case in point. What is the meaning of a
> result set with duplicates? What can you do with it? If I see three
> identical rows, meaning there is nothing returned to differentiate them,
how
> can I, or my client use that information? I may as well just do a count.
> 
> What you find anal I find brilliant. Every "i" is dotted and every "t" is
> crossed in Date's logic. It has symmetry and completeness I have rarely
> found elsewhere.
> 
> Look at it this way: you may argue that there are times when we should
break
> away from the theoretical to get the practical accomplished. But every
time
> you "break away" from the theory, you making an exception you will have to
> keep track of and account for. Yes, you can duplicate data to prevent
joins.
> But make sure you have a trigger to handle the extra update, etc., etc.
> Sometimes it's worth it, sometimes it gets out of hand.
> 
> I enjoyed your remarks.
> 
> Thanks,
> 
> Mike


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: