Re: Can a procedure contain only a SELECT statement?
Date: Sun, 21 Mar 2010 19:10:41 +0100
On 03/21/2010 04:49 PM, Bob Jones wrote:
> "Robert Klemme" <shortcutter_at_googlemail.com> wrote in message > news:80mfq8Fo7U1_at_mid.individual.net... >> On 20.03.2010 23:20, Galen Boyer wrote:
>>> Robert Klemme<shortcutter_at_googlemail.com> writes:
>>>> On 03/19/2010 08:39 PM, Sybrand Bakker wrote:
>>>>> On Thu, 18 Mar 2010 22:26:44 -0400, Thomas Gagne
>>>>> <TandGandGAGNE_at_gmail.com> wrote:
>>>>>> My background is Sybase& SqlServer. On both, due I'm sure to a
>>>>>> common heritage, a stored procedure is capable of being as simple
>>>>>> or complex as the programmer wants. Sometimes, all that is needed
>>>>>> is a select statement. Sometimes even simple projections may
>>>>>> require multiple steps to prepare the last SELECT. Additionally,
>>>>>> stored procedures are capable of returning multiple result sets. I
>>>>>> assumed, incorrectly, such a thing was not so complicated that it
>>>>>> couldn't be easily done inside Oracl
>>>>> Mickeysoft has never understood the Procedure concept, and ignored the
>>>>> formal defintiion and abused it to return a result set.
>>>>> It seems like you belong to the class of sqlserver 'developers' which
>>>>> is so narrow-minded they automatically reject everything done
>>>>> differently by Oracle and start bashing Oracle for it.
>>>>> Luckily sqlserver is incapable of being an enterprise class product,
>>>>> just because of its poor architecture and vendor lock-in, so your
>>>>> 'objections' are futile.
>>>> I would not be too sure of that. SQL Sever isn't as bad as people are
>>>> trying to make it look - and it's gaining ground, especially in the
>>>> area of dealing with larger data sets. Maybe it's not as "enterprise
>>>> class" as Oracle is (or is claimed to be) but the management tools
>>>> with good graphical user interface were there before Oracle had Grid
>>>> Control. Yes, I know - real DBA's use command line, but there are
>>>> situations where a graphical visualization can greatly help.
>>> One of the biggest winning arguments for Oracle, is that it run on
>>> almost all platforms, MS products only run on one.
>> Why is that an argument pro Oracle? >> > > Very simple, choices. That is a major advantage.
I beg to differ. Some do not need the choice, some are only looking for MS based products, some don't care about the OS... On the other hand, if you need to support multiple platforms you either need to make compromises to be able to adjust your product to all of them - or you need significant more development resources. The sheer number of supported OS to choose from is not a value in itself.
Actually I believe "choice" is often overrated. You certainly cannot look at it alone and make that a major selling point for one product or another. If you are building a product for a wide range of application cases from very small to very large then it's probably a good idea to look at the platforms a database product can be run on. But even then you should closely look at the details - it may turn out that supporting one DB product on multiple platforms turns out as expensive as having to support different products altogether. If you do not need to support such a variety of environments then the platform may be totally irrelevant and other aspects such as customer requirements, reusing existing code base etc. might be paramount. Many companies today use more than one OS so the aspect of additional cost for maintaining another platform often is non existent.
-- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/Received on Sun Mar 21 2010 - 13:10:41 CDT