Serge Rielau <sr*****@ca.eye-bee-em.com> wrote in message news:<ip***************@news04.bloor.is.net.cable. rogers.com>...
Bernard Dhooghe wrote: Serge Rielau <sr*****@ca.eye-bee-em.com> wrote in message news:<pb********************@twister01.bloor.is.ne t.cable.rogers.com>...
I thought I answered this row-constructor thread sufficiently very
recnetly....
Hello Serge,
Indeed.
But.
At every release there is hope the SQL92 feature will be there
because:
1. this missing capabability is a lack of orthogonality (which does
not only matters for purists but also for practitioners), if there is
one thing that kills the confidence, respect and usage of a tool
(product in this case, it is not open source)is a lack of
orthogonality
NO, if there is on ething that killd confidence then it is missing
_highly_needed_ features. 2. quite a number of postings in this newgroup ask for it when
talking about searching and scrolling where keys composed of multiple
parts are involved and performance problems are reported
Yes, but:
SELECT COUNT(DISTINCT authors) FROM postings WHERE content =
'ROWCONTRUCTORS'
=> 2
In other words; I admire your persistence. But please grant me that
asking for the same thing by the same person is not the same as asking
for the same thing by many distinct customers.
3. DB2 UDB can does not support what is clearly claimed as being
basic for a relational database: search and processing by content
I'm obviously missing something here.... what are all thsoe customers
doing without this alleged core feature?
Note that there is no law about which features of SQL a given DBMS has
to support.
So: again: when, when, when?
As soon as you, instead of repeating the same pokes buidl a business
case that folks like I can present to their managers to get the resources.
And, no, orthogonality is nice, but it is not a business case.
So far I know of 1(!) example for which I don't understand the business
logic (>= for composit zip-codes).
We are running in circles on this.... and, by golly, we got enough
features requested in this group into the product. It's not that I mean
to be stuborn...
Cheers
Serge
Hello Serge,
My approach is just to say once in a newsgroup posting what I think,
so I will not answer a number of things that you comment on and we all
appreciate I think, even I don't agree.
On your query (result 2) and the business case to managers, these are
facts I will tackle.
The query result has a very low value because I'm the one who uses the
SQL92 qualification I've found in the Melton book on SQL92. But every
time I reply (not issuing it myself as for this one) on the newsgroup
on postings and refer to row value constructors, I answer to the same
problem people encounter when using DB2 UDB in building real life
applications (where composite keys are not an exception at all), so
the newgroup counter is certainly equal the times I replied to
postings in comp.databases.ibm-db2 when suggesting row value
constructors would help.
I refer to Chris Date who in his relational writings was first in
favor of surrogate keys, but changed it's view and accepted that in
people's world, keys can be composed of multiple parts that make sense
part by part and also all together.
Key-indexed files where good for at on-line browsing and scrolling
access and there is no reason a relational dbms could not handle the
feature.
In key-indexed files, the set can not be composed and it is based on
just one file/table, but the cursor can be set and scrolling can go up
and down.
In a rdbms the set can be composed but cursor position is weak and
most of the time/always(?) at the beginning of the set. So row value
constructors are just a partial solution but would be of great help.
Remark: I would see it as follows: split roles in set composition and
cursor positioning (orthogonality):
select * from ... where ... order by c1, c2, c3,... position cursor
at (c1,c2,c3,...) <= > | >= | < | <=) ('...', ...)
but this is no SQL standard as far as I know.
This is why I see row-value constructors as a (first) solution and no
doubt it was introduced in SQL92 to handle real world needs.
Bernard Dhooghe
