Re: when to use a DB

I am not convinced that having large amount of data will justify a DB. Do I have to look at things like is there any complex relationship between those data etc?

In my project data is static and do not change after loaded into the DB (for example previous day statistics information about a network). Only thing I need to do is to generate various kind of reports from that. But, for example, if I can sequentially traverse the table and generate a report, why do I need a DB for?

First I was thinking of a flat file. Then I was considering why not load the data into objects (java or C++), regerate reports, and discard those objects.

But If I look into the future, there may be a need to keep the data for several days (if the customer wants to re-generate an old report, for example).

Siva

Jerry Gitomer <jgitomer_at_erols.com> wrote in message news:<3C86DABE.53CBF289_at_erols.com>...
> siva chelliah wrote:
> >
> > When you start a project, sometime you discuss if we need a DB or not
> > for that project.
> >
> > What are the guidelines on when to use and when not to use a database
> > for your projcet?
> >
> > I do not want to use a DB and incur un-necessary overhead. So I want
> > to make sure I really need a DB in our current project we are just
> > starting to design.
> >
> > Thanks,
> > Siva
>
> Let me say up front that I have been a DBA for over a decade.
>
> If you have a database server and it isn't fully saturated the
> question
> should be; "How do you justify not using a DB?"
>
> The only argument against using a DB and its accompanying 4GL
> tools is that
> performance MAY not be as good as a perfectly coded 3GL
> application.
>
> On the other hand the use of a DB will substantially reduce
> development
> time and cost when getting your application up and running and
> will also
> cost far less to modify over the course of its life.
>
> If this is not your experience your developers do not have a
> proper
> understanding of a DB and are trying to force it to behave as a
> 3GL
> tool. In which case your should either retrain or replace
> them. (In
> most cases retraining is the preferred alternative.)
Received on Wed Mar 13 2002 - 20:21:50 CET