Path: newssvr20.news.prodigy.com!newsmst01a.news.prodigy.com!prodigy.com!newsfeed.cwix.com!news.netins.net!not-for-mail From: "Dawn M. Wolthuis" Newsgroups: comp.databases.theory Subject: Re: Total Cost of Ownership Date: Thu, 15 Apr 2004 16:57:40 -0500 Organization: netINS InterNetNews site Lines: 49 Message-ID: References: NNTP-Posting-Host: 199.120.93.7 X-Trace: news.netins.net 1082066265 20159 199.120.93.7 (15 Apr 2004 21:57:45 GMT) X-Complaints-To: usenet@netins.net NNTP-Posting-Date: Thu, 15 Apr 2004 21:57:45 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: newssvr20.news.prodigy.com comp.databases.theory:25427 "Anthony W. Youngman" wrote in message news:MldkiaDA3ufAFwBN@thewolery.demon.co.uk... > In message , Laconic2 > writes > >> Stagnation, inadequate communication among all players, high risk of > >making > >> any change, severe procedures for making changes, application performance > >> including performance issues related to the database, ease of reporting > >> against the database including ease for users to have and maintain a data > >> catalog (so they can "shop" for the data they need); mitigation of > >> client/server & version skew issues, and a bunch more -- these might not > >be > >> the most important -- I'll think more about it. > > > >I've repeatedly sped up SQL queries by factors of ten. And most of the > >time, I've taken a close look at the logic behind the query, before diving > >into optimizing it. I think a lot of bad queries have been written by > >people who just don't understand the data. > > Relevant to the TCO question - because of the way Pick stores its data, > it's actually damn hard - in a system that was properly designed in the > first place - to speed up a Pick query. > > And it's also relatively easy to prove that there is very little room > for improvement. > > Cheers, > Wol Great point, Wol! In fact, when talking to a customer a few years ago who only knew PICK in their IT career but was learning SQL, they asked -- why do you have to "tune your query"? Good question. Not only do SQL programmers improve performance in straight forward ways, they have to think about various ways of joining tables and such. I just heard from a colleague who migrated customers from PICK to a SQL-based database and then back again and the users were thrilled to get their query language back. With SQL the myth of actual end-user queries has been around for a couple of decades while with PICK end-users have been querying the database since 1969 (with NO risk of cartesian cross-products!). Cheers! --dawn