DBMS, May 1996
On the subject of domains, data types, and related matters (see "Celko Fights Back," February 1996, page 6). OK. It is now clear to me that to attempt yet another reasoned, blow-by-blow rebuttal would probably just be to prolong the agony and would almost certainly be a waste of my time. Suffice it to say that:
a. I find Celko's reply to be (once again) rife with confusion, mistakes, irrelevancies, and misrepresentations of my own position.
b. In particular, it fails to address most of the points I was making in my letter (DBMS, January 1996, page 6) to which it was meant to be responding.
c. I therefore suggest to readers who might still be interested in this subject that they just carry out a careful, side-by-side reading of the two letters in question and make up their own minds.
C.J. Date
Healdsburg, Calif.
I saw Judith Hurwitz's article in the January 1996 issue of DBMS (page 12). I agree that the scenario of Internet-as-infrastructure has a high probability of success.
Here is another interesting slant on the topic. Web technology can turn departmental systems into corporate and intercorporate applications. By putting a Web interface on an existing departmental application, the application becomes immediately available across a company.
This has interesting effects. For example, one of our customers is taking an existing Oracle database of chemical compounds and putting it on the internal Web. An application and database that was previously accessible only by a small number of users is now available across a corporation. This is something that was previously only possible through a central MIS organization. This ease of application development and deployment will change the way companies think about information systems, and the Web will fast become a de facto part of the infrastructure.
Bob Bickel
Mount Laurel, N.J.
bickel@bluestone.com
I continue to be puzzled by authors who knock SQL for its lack of strength in generating useful reports. I believe the "Q" stands for "query." Otherwise we would have called it SRL for "report."
Ralph Kimball's frustrations presented in the January issue of DBMS are typical. Take the time and energy devoted to the criticism and go out and purchase a good off-the-shelf report writer designed for RDBMSs. Most can handle the "crosstabs" type of output he seeks.
I am not putting SQL on a pedestal. I am well aware of its weaknesses. Chris Date has done an admirable job over the years of pointing out its inconsistencies and shortcomings. But those problems are worth mentioning because they occur within the realm of even simple use of SQL and are innate qualities of the language's logic and
assumptions.
Kimball's criticisms focus more on the frosting than on the cake. Use SQL for what it does best, and use report writers for what they do best. In my experience, as you move away from the basic, core functionality of a tool and begin to "stretch" it to its limits, the cost/benefit turns negative very quickly. You are better off getting a more appropriate tool for your needs.
Irv Cantor
Edison, N.J.
icantor@ix.netcom.com
I appreciate your comments. My goal in these columns is to most effectively match the data we have in our data warehouses with the needs and skills of modern IS departments. I feel like I live in the basement of IS departments. I believe that IS departments are trying overwhelmingly to produce the equivalent of reports, and that the current tools are particularly thin veneers over plain old SQL.
I don't share your view that all we need is a standard report writer that can do crosstabs. Such a report writer is too far downstream from the data to do anything more than rearranging additive values on the screen. I have a several-foot-high stack of sample reports from IS shops, and I have annotated them with simple and complex comparative measures requested by end users. More than half cannot be created by downstream crosstab tools. By moving the comparison and sequential operations upstream to the SQL engine where we can express our intentionality more directly, we can make our tools simpler and spend more time analyzing information rather than building report scaffolding.
-- Ralph Kimball
Rob Rothkopf (CompuServe ID 72002,742) of MBMS found an error in the solution to my March puzzle. The solution should have qualified all the column names in the subquery to read:
DELETE FROM Consumers
WHERE fam IS NULL
AND (SELECT COUNT(*)
FROM Consumers AS C1
WHERE C1.address =
Consumers.address) > 1;
The rule for nested subqueries is that they resolve unqualified column names by going to the nearest from clause. This search never left the subquery, because both address and C1.address resolved to the same column.
Some SQL products allow you to use a correlation name on the table in the delete from clause, but this is not part of the SQL-92 standard.
Joe Celko
Atlanta
I was just reading the Coming Next Month section of DBMS. I am disturbed by the fact that you guys NEVER compare CA-Visual Objects when you compare tools like Visual Basic, Delphi, PowerBuilder, Oracle Power Objects, and so on.
I certainly hope that your reviewer makes clear the enormous differences in the three products being reviewed. One is a 4GL interpreter, one is a visual development environment for an interpreted language, and one is a native compiler with a true OOPS language and visual development tools. This last category is exactly the same category as that of CA-Visual Objects. I really don't understand the way the press ignores this wonderful new Xbase-derived, fully OOPS language.
I am not connected to Computer Associates and am just interested in fair play in the media when it comes to the available tools.
George L. Smith
tksoft@pipeline.com
Thanks for taking the time to share your opinion. This issue of DBMS (see page 55) compares CA-Visual Objects, Visual FoxPro, and Visual dBASE. I realize CA-Visual Objects is no longer simply an Xbase compiler, but Computer Associates (CA) describes this product as a desktop tool to build Windows applications. While I assume that some developers use CA-Visual Objects to develop client/server database applications, Computer Associates positions CA-Open Road as its tool for building enterprise-scale (hundreds or thousands of users) client/server applications. If you believe CA is not positioning CA-Visual Objects properly, you should lobby Computer Associates as well as the media.
CA's positioning is one factor to consider, and it may not always be consistent with how developers use the product. While I receive many requests for comparisons of Visual Basic, PowerBuilder, and other tools often used to build client/server applications, your message is the first one to mention CA-Visual Objects.
Once again, I appreciate your opinion and will monitor CA-Visual Objects' market positioning more closely. -- Ed.
In the April DBMS, page 40, Platinum Software Corp. was listed as the maker of DB-Vision. The sentence should have read: "DBVision by Platinum Technology Inc." DBMS regrets this error.