Re: Total Cost of Ownership
Date: Thu, 15 Apr 2004 16:57:40 -0500
"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> In message <ufmdnTco6-i6zuXd4p2dnA_at_comcast.com>, Laconic2
> <laconic2_at_comcast.net> writes
> >> Stagnation, inadequate communication among all players, high risk of
> >> any change, severe procedures for making changes, application
> >> including performance issues related to the database, ease of reporting
> >> against the database including ease for users to have and maintain a
> >> catalog (so they can "shop" for the data they need); mitigation of
> >> client/server & version skew issues, and a bunch more -- these might
> >> 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
> >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.
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 Received on Thu Apr 15 2004 - 23:57:40 CEST