Re: ORDER BY in VIEW not working
- From: Herb Caudill <herb@xxxxxxxxxxxxxx>
- Date: Tue, 21 Mar 2006 23:18:06 GMT
Of course lots of people care about performance, and they should. My
point is that performance is not the only thing that matters, something
that seems lost on many contributors to this newsgroup. If you have a
one huge database and lots of developers, it makes sense to focus on
performance. If you have lots of small databases and just a couple of
developers, which is my situation, it makes better business sense to
focus on developer productivity instead. For me database performance and
scalability are simply non-issues. On the other hand, code reuse,
encapsulation of logic, and things like that are absolutely paramount.
(Here's a horrifying example for you: We deliberately use SELECT * where
possible, because it means that we can add a field to an application and
only have to touch our code in three places, instead of twenty.)
In the past Microsoft has been very good about balancing performance
against developer productivity, and about preserving backward
compatibility as well. There are a number of solutions that they could
have come up with here that would have been preferable to breaking
existing applications that depended on an application's previous
behavior, even when that behavior was undocumented.
The fact of the matter is that SQL server used to work the way most
naïve users would expect it to work - that is, views and functions with
an ORDER BY clause returned ordered results. This worked 100% of the
time in my experience, and I depended on it. The fact that there was a
footnote in an RFC or a technical specification somewhere the explained
that this was not guaranteed is beside the point; as far as I'm
concerned this is a breach of backward compatibility, and your
explanation that the new approach gives me better query optimization
does not interest me at all.
Even if it did, as RickW has pointed out, it makes no sense - even from
a theoretical perspective - that SQL would lack an intrinsic object able
to return ordered data. If a stored procedure can, then why can't a view
or a function? Most intelligent programmers approaching SQL for the
first time would assume that ordering of data is a service that a
database language should be able to provide - indeed, one that is best
left to the database as opposed to the client code - and that this
service could be incorporated into objects (views/functions/procedures)
that can in turn be used by other objects. I understand the performance
issues you raise, but there are any number of ways that Microsoft could
have pleased me *and* the massive-scalability crowd: whether with more
intelligent and flexible optimization, or using a global switch, or a
specifier that could be added to a view's definition - or simply by
favoring performance if there is no ORDER BY clause present, and
respecting the ORDER BY clause if it is there. As they say, it's a
simple matter of programming. I think this is a rare instance of simple
laziness on Microsoft's part.
*** Sent via Developersdex http://www.developersdex.com ***
.
- Follow-Ups:
- Re: ORDER BY in VIEW not working
- From: --CELKO--
- Re: ORDER BY in VIEW not working
- From: Erland Sommarskog
- Re: ORDER BY in VIEW not working
- From: David Portas
- Re: ORDER BY in VIEW not working
- References:
- Re: ORDER BY in VIEW not working
- From: Erland Sommarskog
- Re: ORDER BY in VIEW not working
- Prev by Date: Re: Using OSQL and DTSRUN
- Next by Date: Re: ORDER BY in VIEW not working
- Previous by thread: Re: ORDER BY in VIEW not working
- Next by thread: Re: ORDER BY in VIEW not working
- Index(es):
Relevant Pages
|
Loading