Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!news-out.cwix.com!newsfeed.cwix.com!ctb-nntp1.saix.net!not-for-mail
From: Billy Verreynne <vslabs@onwe.co.za>
Newsgroups: comp.databases.oracle.misc
Subject: Re: TOP N Query
Date: Thu, 12 Dec 2002 08:37:42 +0200
Organization: Verreynne Software Labs
Lines: 42
Message-ID: <at9avl$77$1@ctb-nnrp2.saix.net>
References: <at51pt$ebu$1@news.vsnl.net.in> <at6jot$kgg$2@ctb-nnrp2.saix.net> <at6mbb$i3$1@news.vsnl.net.in> <873cp4xlu7.fsf@blind-bat.une.edu.au>
NNTP-Posting-Host: 198.54.202.208
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: ctb-nnrp2.saix.net 1039675189 231 198.54.202.208 (12 Dec 2002 06:39:49 GMT)
X-Complaints-To: abuse@saix.net
NNTP-Posting-Date: 12 Dec 2002 06:39:49 GMT
User-Agent: KNode/0.7.1
Xref: newsfeed1.easynews.com comp.databases.oracle.misc:90461
X-Received-Date: Wed, 11 Dec 2002 23:39:25 MST (news.easynews.com)

Tim X wrote:

>> >The proper way would be to design the database and table to meet the
>> > end-user requirements.. :-)
>>
> Not sure I can agree here. I've seen too many databases which were
> designed with the end user requirements being considered to be the
> primary goal at the cost of propper modelling of the data and
> identification of correct entities and their relationships. The result
> is often a "de-normalized" database design.

I agree Tim. I was by no means advocating not to use Codd and design a 
"proper" database. However, when it comes to the physical implementation, 
there are numerous way to skin the cat. Without knowing how the database is 
going to be practically used, the wrong decisions can easily be made.

> While I don't think you should ignore end-user requirements, they
> should not have too much influence in modelling and design. 

Agree. But there are also a physical design. Clustering. Partitioning. Etc. 
There are PL/SQL, JAVA, Pro*C. What to use where. Knowing _how_ the 
database is going to be used, is critical in designing the physical layer, 
deciding on the access layer, etc.

> It is also
> difficult to predict what the end user requirements will be. 

Yep. But then predicting should not be in the equation at all. End user 
requirements must be detailed in the URS and Functional Specs of the 
system. And signed. They just love to move the goalposts and paint them in 
a different colour. ;-)

> However, I think it is a credit to the original
> designers this database has managed to still be productive and it has
> been possible to incorporate a web interface without too many
> difficulties .

Yes. A good solid design goes a very long way. Wish I could personally see 
one or two of them on the databases I'm looking after...

--
Billy
