Picking correct DBMS

Picking correct DBMS

Post by leebe » Mon, 18 Dec 1995 04:00:00



I've started researching the whole matter of choosing a database
server for my company, and the scope of this investigation is
mind-boggling.

At this company, there is already a strong pro-MicroSoft
predisposition; they want to use NT SQL Server. A PB consultant has
shown up, telling them that NT SQL/Server will do everything they
want.

I have reason to be circumspect: within a year, they will be faced
with processing 3 million _NEW_ call detail records (they are a
nascent long-distance reselling phone company) PER DAY, but sending
out _MONTHLY_ bills to roughly 100 different customers (other phone
companies) -- easily 5 billing cycles per month.

I think you can see why I am concerned about commiting them to a MSFT
course of action.

The basis of my concerns are 2-fold: performance & portability:

Since they are going to have _LARGE_ transactional requirements within
a year or two, I am worried that MSFT SQL Server WON'T be able to take
the pounding. Sure, a Quad-Pentium SMP NT box is cool, but can NT
actually get the job done? My suspicion is their req's indicate a
UNIX-based/RISC-based system _NOW_ (an RS6000 or SPARC). I'm not
aware, at least yet, that there is a NT SQL Server for anything other
than Intel.

Since MSFT database server offerings are strictly NT or Novell; there
are no other OS platforms to migrate to. I understand NT runs on Alpha
& MIPs and that SMP provides an awesome boost in power, but I'm
concerned that even with MIPs or Alpha hardware, NT won't provide the
requisite power they'll need in 2 years. By then they couold be faced
with the transition cost of migrating away from NT SQL Server to the
nearest relative, Sybase - or worse, a massive re-write over to
Oracle. Perhaps this transition from SQL Server to Sybase used to be
easy, but Sybase & MSFT are going off in different directions these
days.

Any comments?

P.S.

Then there's the whole issue of data wharehousing....
First of all, there's an existing Xbase culture (FoxPro) that's
well-developed, but unhappy with the requirements of Visual FoxPro,
hence, they're leaning towards Vis. dBase 5.5 / Delphi. They are
accustomed to working stand-alone and taking care of themselves,
hence, I'd like to give them an easy-to-use inexpensive database
server for the wharehousing (mostly aggregates and lookup tables).

I've looked at MSFT SQL Server, WatcomSQL (now Sybase SQL Anywhere) &
Borland's Interbase (The aforementioned PB consultant told me it
crashes 4 times more often than MSFT SQL Server). Any comments?

TIA,

Lee

 
 
 

Picking correct DBMS

Post by GT Cher » Mon, 18 Dec 1995 04:00:00


dude-
i empathize with your problem, but i can see that you are at the very
first stages of your quest. your path will become more clear as you
progress. you may develop some opinions such as mine:
  1) the cost factor is very important upfront when you have to sell a
choice with a big price tag to management. work with your vendor to get
the upfront layout as low as possible even if the long term cost remains
the same. management understands paying for quailty and functionality
once it is shown in practice, not in theory. your vendor knows that
after filling needs, reducing risk is the heart of selling to management.
if your choice makes users happy, no one will remember the cost.

  2) don't let current evaluatins mix with future evaluations. for
instance, when you hear pundits say that ms-sql does not handle large
databases, don't presume that if your db will be large in 2 years that
ms-sql is in concrete and won't be able to handle it. determine the scope
of your project and recommend the best product for that scope. technology
changes within 2-3 years and you will be buying something again at that
point. if your recommendation works well for the next two years, and you
don't go too far from standards, you are a hero. over the span of that time,
the criteria for the next step will build for the next evolution.

  3) this trick is to analyze in order to eliminate choices, not propagate
them. for instance, if you find that the db will be primarily read, then
a red brick moves to the top of the list and the super-optimized update
guy drops off the list if that need is not there for the scope of your
project.

its not a lot of fun choosing a db, but its very satisfying once done,
kind of like running a marathon. all along the way you think of good
reasons to quit, but once you finish you get a free t-shirt.

hope you get lots of help from the other folks. just remember that all of
our advice is free and worth what you pay for it.  8-}

--

"Comfort the afflicted: Afflict the comfortable."

 
 
 

Picking correct DBMS

Post by Paul Waug » Mon, 18 Dec 1995 04:00:00


I know that the NATWEST bank have a one tera byte database
on SQL server runing on two SEQUENT's. OK its not a major
transaction based databases but it does through alot
of information around.

Personally we have made a strategic move away from ORACLE
to SQL Server purly on a cost benefit bases. But now we know
we are commited to the product we have found out that there is
hardware available for major transaction processing. Our future
finance and ordering systems will be running on DEC ALPHA 2100's
and now of course the 4000 range is available.

I hope this help's

Paul
--
---------------------------------------------------------------------------


---------------------------------------------------------------------------

 
 
 

Picking correct DBMS

Post by leebe » Thu, 21 Dec 1995 04:00:00



>dude-
>i empathize with your problem, but i can see that you are at the very
>first stages of your quest. your path will become more clear as you
>progress. you may develop some opinions such as mine:

Thanx for presenting your POV. You've clearly been thru the whole
ritual. This will be a great help.
 
 
 

Picking correct DBMS

Post by airr.. » Fri, 22 Dec 1995 04:00:00


Very good explanation. Clap! Clap!

 
 
 

Picking correct DBMS

Post by Jonathan Euni » Sat, 23 Dec 1995 04:00:00



but not this part:

Quote:> technology changes within 2-3 years and you will be buying something again
> at that point. if your recommendation works well for the next two years,
> and you don't go too far from standards, you are a hero. over the span of
> that time, the criteria for the next step will build for the next
> evolution.

This may be true for workstations and PCs, and maybe even true for LAN
servers, but it isn't true for large-scale DBMS and OLTP systems.

These often "run until the iron rusts out from beneath them."  God
knows, there are enough codes still running and still tied to JES, CICS,
ACMS, or whatever--twenty or more years later.  Client/server makes
portability more feasible, but hardly makes it auto-magical or painless.
Switching costs are likely to be high, and significant parts of the
products and architectures you choose now are likely to be with you ten
years into the future.  Don't blithely expect that you will be able to
rewrite your choices in 2-3 years.

--
Jonathan Eunice                       Director, client/SERVER Companion

 
 
 

1. Picking correct DBMS

I've started researching the whole matter of choosing a database
server for my company, and the scope of this investigation is
mind-boggling.

At this company, there is already a strong pro-MicroSoft
predisposition; they want to use NT SQL Server. A PB consultant has
shown up, telling them that NT SQL/Server will do everything they
want.

I have reason to be circumspect: within a year, they will be faced
with processing 3 million _NEW_ call detail records (they are a
nascent long-distance reselling phone company) PER DAY, but sending
out _MONTHLY_ bills to roughly 100 different customers (other phone
companies) -- easily 5 billing cycles per month.

I think you can see why I am concerned about commiting them to a MSFT
course of action.

The basis of my concerns are 2-fold: performance & portability:

Since they are going to have _LARGE_ transactional requirements within
a year or two, I am worried that MSFT SQL Server WON'T be able to take
the pounding. Sure, a Quad-Pentium SMP NT box is cool, but can NT
actually get the job done? My suspicion is their req's indicate a
UNIX-based/RISC-based system _NOW_ (an RS6000 or SPARC). I'm not
aware, at least yet, that there is a NT SQL Server for anything other
than Intel.

Since MSFT database server offerings are strictly NT or Novell; there
are no other OS platforms to migrate to. I understand NT runs on Alpha
& MIPs and that SMP provides an awesome boost in power, but I'm
concerned that even with MIPs or Alpha hardware, NT won't provide the
requisite power they'll need in 2 years. By then they couold be faced
with the transition cost of migrating away from NT SQL Server to the
nearest relative, Sybase - or worse, a massive re-write over to
Oracle. Perhaps this transition from SQL Server to Sybase used to be
easy, but Sybase & MSFT are going off in different directions these
days.

Any comments?

P.S.

Then there's the whole issue of data wharehousing....
First of all, there's an existing Xbase culture (FoxPro) that's
well-developed, but unhappy with the requirements of Visual FoxPro,
hence, they're leaning towards Vis. dBase 5.5 / Delphi. They are
accustomed to working stand-alone and taking care of themselves,
hence, I'd like to give them an easy-to-use inexpensive database
server for the wharehousing (mostly aggregates and lookup tables).

I've looked at MSFT SQL Server, WatcomSQL (now Sybase SQL Anywhere) &
Borland's Interbase (The aforementioned PB consultant told me it
crashes 4 times more often than MSFT SQL Server). Any comments?

TIA,

Lee

2. updating a linked field

3. What is the correct plural of DBMS

4. Unexplainable Database Datafile Growth

5. SQL-SELECT not picking up correct dates

6. ADO and Swedish

7. question about picking the right database - corrected

8. PLPGSQL vs. PLSQL (Oracle)

9. PICK dbms/os on UNIX

10. The Pick dbms

11. How to pick a DBMS

12. ADO thinks DBMS is done, but DBMS ain't done

13. Please recommand some newsgroups about spatial dbms and spatiotemporal dbms