Re: Total Cost of Ownership

From: Laconic2 <>
Date: Sat, 10 Apr 2004 16:04:34 -0400
Message-ID: <>

> It is pretty much "for" the same purposes as SQL Server.

And what is SQL Server for?

I hope you won't think I'm just being difficult here, because I'm not.

I believe this whole question of "what is it for" is a lot more subtle than most people think it is.

And I think that buying the wrong tool for the wrong reasons can drive your TCO way up.

> include companies that switched from PICK to Oracle and increased their IT
> staff by 400% to accomodate as well as needing bigger hardware and having

And do you have evidence from companies that switched from Oracle to PICK and were able to cut their IT staff by 75%, with no loss of service level?

The reason I ask is that you need to factor out time from the variables you are looking at.

Another choice would be to look at companies that started with PICK and stayed with PICK. That way you could factor out the cost of change.

> Cost of ongoing support -- training for personnel who make changes, risk
> associated time required to make a change, design of the database that
> permits changes of many kinds to be made handily, software languages
> (including application software and constraint logic) that lead to fewer
> bugs and help with the QA processes, procedures that are tight enough to

I think you are onto something here. But I think it's due at least in part, to widespread ignorance.

Let me go back, briefly to some earlier discussion. In the OTLT thread, the argument against creating a new
table whenever a new code type (and therefore a new entity) is discovered was, after a lot of back and forth, that having different versions of the database in the field would create an unworkable support problem.

But that ignores data independence. How much SQL DML have you ever seen that can be broken
by a subsequent CREATE TABLE? Except in extremely pathological cases, it just isn't going to happen.

Yet people treat CREATE TABLE as if it were some sort of earth shattering undermine of the whole system's robustness.

Not that I want each user of a DB creating his own tables... but I don't even mind that as long as each one has his own schema. But I'm wandering back into how it works rather than what it's for, here.

> Stagnation, inadequate communication among all players, high risk of
> 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
> 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.

> I suspect these databases
> might be poo-pooed by RDBMS folks as "file systems" much as PICK is (I
> KNOW that, however).

Maybe this leads me back to the beginning....

What is a DBMS for? (notice I didn't say RDBMS)  What is a file system for? Received on Sat Apr 10 2004 - 22:04:34 CEST

Original text of this message