Re: Profiler tool

First of all you unwittingly expose a great strength in Oracle (which I have no idea if it exists in SQL Server): Your Oracle example is type-safe and the SQL Server example is not. You could change the select statement in the SQL server declaration and you would have to wait for your client program to crash if anyone depended on the fields returned (the "rowtype").

Second of all, your Oracle example had encapsulation where your SQL Server example did not. You created a global function in SQL SErver where in Oracle you created a package (you get points for exercising the principle of encapsulation, though!).

Lastly, I will ask you a question: Which kind of programming would you expect to see in a big project? Your SQL Server example is typical of what I would type into the "immediate" box of VB while testing out a running program. Your Oracle example is close to what I routinely write for my server-side code.

I am not going to go into a diatribe about packages vs global functions and the design implications and impacts of each (or about type-safe vs type-unsafe code for that matter), but it's enough to tell me why you are unhappy with the Oracle code you provide. Could it be smaller? Definitely. As an experienced developer and DBA would I want it any smaller? Certainly not.

Dont; give up on Oracle just yet. It may look too wordy when you compare to the one-liner SQL Server "equivalent" you provide, but trust me, in Oracle and in large project development design matters a lot. Your Oracle example has great advantages over the one-liner SQL SErver equivalent. It's almost like the difference between OOP and functional programming. Received on Tue Jun 05 2001 - 02:48:04 CEST