Re: When and when not to put information in a database.

In message <3db71c8a.0302271229.77b100b2_at_posting.google.com>, Jesse Connell <me_at_jesseconnell.com> writes

>My proposed solution:
>
>I've developed (on my own time) a custom data storage application (COM
>singleton, hosted in a Windows Service, if you're curious) which
>serves as a central host for this data. It's simple, it's clean, and
>it's FAST. It has all the flexibility needed, the code is not complex
>or large. It has all the locking necessary to make
>reading/writing/other operations safe. Reading, inserting, modifiying
>data is simple and flexible. It uses the LAN/domain security policy,
>so some users/processes can read/write, some can read, some can
>backup/etc. and some can't touch it. This took me about two weeks.
>
>Finally, here's the catch. This methodology is frowned upon by the
>powers that be in my company. It's information that's not being
>housed in a database.

If that really is the objection then I can't see any way round it. On the other hand I think that objection, as it stands, is hogwash. The physical implementation of the database is irrelevant as long as it delivers the data you want, when you want it.

Of course behind the simple objection there are likely to be real technical arguments, which you haven't mentioned (possibly because nobody has mentioned them to you.)

Can your system reliably deliver what is required? Can you prove that it can? Is it supportable?

Even if you can come up with convincing technical arguments there are inevitably political issues too. If you want to make a change from the generally accepted way of doing things you need to look at how it affects each of the decision-makers. Put yourself in their shoes. Work out what they fear may go wrong and put together a proposal that allays any fears they may have.

-- 
Bernard Peek
bap_at_shrdlu.com
www.diversebooks.com: SF & Computing book reviews and more.....

In search of cognoscenti