C.J. Date
Healdsburg, Calif.
The authors also make a point that empty index sets are not defined and that this is strictly a convention. They then have an exercise at the end of that chapter that asks the student to give several interpretations of some "Big Sigma" expressions with index start and stop values that do not define a proper series of cardinal numbers. They then announce which ones they prefer.
Going back to section 1.2.3, "Sums and Products," exercise 23 of Knuth's The Art of Computer Programming, Vol. 1, "Fundamental Algorithms" (Addison-Wesley, 1973), the author asks the student to explain why it is a good idea to define the summation and product of an operator with an empty set as zero and one respectively.
-- Joe Celko
I enjoyed the article and I hope it will put me on the right track to convincing our folks to use a product such as DB2 to decentralize our mainframe data.
Ralph Tillery
rtillery@mail.uams.edu
I have a comment on Judith Hurwitz's column "New Hula Hoops and Other Trends." (See DBMS, October 1996, page 14.) Right on! I could not agree with her more. It seems as if every week I hear another presentation by an Internet company saying how the Internet will solve all of the data access problems and will reduce development from the client/server paradigm of three-to-six months to a few weeks. Hearing such proposals doesn't bother me as much as seeing senior managers at firms sit and listen unquestioning.
It all reminds me of a consulting company that told a customer that there is no need for requirements, design, and testing: This is client/server, and we can do it all right in front of you. Needless to say, shortly after that the consulting firm changed its deliver schedule -- they increased it by six months and eventually got kicked out of the project for failure to deliver what was asked.
It seems as if everyone is looking for a magic solution to good old-fashioned diligence. Keep the faith!
Fred Lengerich
Sybase Inc.
(The views expressed in the above letter are those of the writer and do not necessarily reflect the views of Sybase.)
Our manual "What's New in SQL Server 6.5," which comes with the 6.5 software package, discusses our support for ANSI-standard join clauses on page 155 under "Joins" and under the SELECT statement on page 216. On page 219, the manual states, "The following types of ANSI joins are permitted: CROSS JOIN, INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER. Cor Winckler wrote the individual review of SQL Server 6.5 for the same DBMS issue; on page S26, he says, "A new addition in version 6.5 is the ANSI SQL syntax for full and partial outer joins."
There is also a problem in Rennhackkamp's October 1996 column in DBMS. (See "Performance Tuning," page 85.) Rennhackkamp chides us for not having as many tuning "knobs" as databases such as Oracle and Sybase. He then failed to mention any of our sophisticated tuning parameters such as optimizer hints, pinned tables, and CPU affinity mask. He specifically refers to "SQL Server 6.5" in the article, but his information seems to come from SQL Server 4.2. SQL Server 6.5 supports an extensive list of tuning parameters, including many more than the article listed.
Tom Kreyche
Microsoft Corp.
DBMS apologizes for these errors. SQL Server 6.5 does support the ANSI outer join syntax. And Microsoft SQL Server 6.5 and 6.0 (the version that followed 4.2) did introduce many new tuning parameters.
-- Ed.
The first line of the where clause establishes the OUTER JOIN. This may not be a "proper" OUTER JOIN, but the (+) is Oracle's implementation of one. The first subquery limits s0.sal_date to the most recent sal_date for an employee. The second subquery limits s1.sal_date to the next most recent sal_date for the same employee by excluding the sal_date that matches s0.sal_date. If there is no second sal_date for an employee, then the null values of the outer join are used.
Thomas E. Berendt
Statistics of Income, IRS
Ogden, Utah
select s0.emp emp, s0.sal_date sal_date, s0.sal_amt sal_amt, s1.sal_date sal_date, s1.sal_amt sal_amt from salaries s0, salaries s1 where s0.emp = s1.emp(+) and s0.sal_date != s1.sal_date(+) and s0.sal_date = (select max(sal_date) from salaries where emp = s0.emp) and (s1.sal_date = (select max(sal_date) from salaries where emp = s0.emp and sal_date != s0.sal_date) or s1.sal_date is null);
| EMP | SAL_DATE | SAL_AMT | SAL_DATE | SAL_AMT | ||
| Tom | 1996-12-20 | 900 | 1996-10-20 | 800 | ||
| Harry | 1996-09-20 | 700 | 1996-07-20 | 500 | ||
| Dick | 1996-06-20 | 500 | (null) | (null) |