Re: buying a database versus making one

From: Ed prochak <ed.prochak_at_alltel.com>
Date: 22 May 2002 10:08:49 -0700
Message-ID: <e51b160.0205220908.e38ff7d@posting.google.com>

"Soda Badada" <lachine_at_speakeasy.org> wrote in message news:<ueluarhi7nnvef_at_corp.supernews.com>...
> Can anyone refer me to info that documents the cost buying a database versus
> making one?
>
> thnx
> Tim

You actually have 3 alternatives:

*build your own from scratch or other basic parts
*Buy from one of the many DB vendors
*use/modify a freeware database

IMO your application requirements would have to be very specific to justify the cost of developing your own database. Some reasons I can imagine someone giving for building their own DBMS include: 1.resources on the computer cannot support a modern DBMS (commercial or freeware)

2.your requirements are beyond the capabilities of a DBMS
3.your requirements are below the need for a DBMS
4.you have too much time in the project schedule and you need to keep

people busy
5.we cannot afford a DBMS license for each widget

Responses for each of the reasons:

1. Even in embedded applications there are many cases where the computer resources (cpu, memory, disc) can easily support a commercial or freeware database. The cost (time and money) for doing it yourself are not justified.
2. Okay, maybe you need microsecond responses for table scans over a billion records. Does your development team really have the skills to do this better than, for example, an ORACLE cluster?
3. Maybe, you really just need an indexed file library.
4. With all that development time wouldn't be better spent building a better front end application instead of mucking around in building a backent database?
5. There are many inexpensive DBMS products available. Some require only a fee for development copies. and yes there's also freeware DBMS products.

My suggestion: think long and hard about your requirements. Only then should you begin to consider this question. And then only consider it in the light of your requirements. Received on Wed May 22 2002 - 12:08:49 CDT