<crazy insults snipped>
> The basic principle of a tiered architecture is that display is done in
> the front end and never in the back end. This a more basic programming
> principle than just SQL and RDBMS.
<another useless insult snipped>
Celko, the OP wasn't talking about modeling, he was talking about
querying. Are you saying that this kind of operation should only be
performed in PHP, Java, VB, Python, Ruby, etc? And never in SQL?
Nevermind the performance benefits of doing it in SQL.
Nevermind the opportunity to create a materialized view that could
speed up the operation.
Buck
> Why do you wish to destroy first normal form (1NF)?
>
[quoted text clipped - 10 lines]
> Oh, if you still want to be bad programmer, use a cursor so you can
> control the ordering. There are a lot of kludges like this posted.
With this type of thinking, why are there any aggregate functions:
count, sum, avg, etc.? Shouldn't they also be achieved in the front end?
An (or several) aggregate function(s) that worked with strings as
opposed to just numbers, would be greatly appreciated. The whole world
does not consist of accountants and statisticians, SQL xxxx standards
not withstanding. In a perfect world, there would be a way to
declare/define user aggregate functions as well as table and scalar
functions, but a new concept, static, might need to be introduced.
--CELKO-- - 17 Dec 2005 19:04 GMT
No. An aggregate functions return a *scalar value* of a group
characteristic. This concatenation returns a list *structure*. That
list can be in any order unless you use a cursor and procedural code to
sort it. An aggrgate function that returns an array would also be
wrong becuase it woudl violate 1NF and the results would not be a
table.
>> there would be a way to declare/define user aggregate functions as well as table and scalar functions, but a new concept, static, might need to be introduced. <<
You would be surprised with what you can do using nested function calls
and expressions right now.
People that argue it is cheaper to do this kind of reporting in the
database forget about the cost of searching, string handling and
disassembly in the front end. The real trick is to have a reporting
tier that holds the data and does the dirt work. The transfer of data
from the RDBMS to the middle tier can be reduced and compressed so that
you do not waste time.