Re: Design question

sans11_at_hotmail.com (san) wrote in message news:<8e29a54a.0305042101.37d0583e_at_posting.google.com>...
> 71062.1056_at_compuserve.com (--CELKO--) wrote in message news:<c0d87ec0.0305041307.69626512_at_posting.google.com>...
> > >> Is there a better way? Keep in mind that I am required to use an
> > RDBMS. <<
> >
> > Given that requirement, you are dead. A better way to handle
> > documents is to use a textbase or document retrieval product.
> >
> > The basic idea of a relational DBMS is that you know all the
> > attributes of the data model before you load the data into the schema.
> > You do not "make it up" as you go along. You can kludge something
> > together, but it will perform so poorily and be so large that it will
> > be useless in a year.
> >
> The thing is that the number of attributes in not very large (unlike a
> text database where there are several words that need to be indexed -
> we are not looking for full-text search). And, the system has
> transactional aspects to it.
>
> Regards,
> Sandeep
> > Many years ago, I had a consulting job with Southern California
> > Edison. They were trying to put their Labor Law library on a database
> > and had originally wanted to use DB2. The law library was contracts,
> > laws, court decisions, etc. -- all documents, no records. I suggested
> > a textbase that looked like Lexis or WestLaw on the front end so their
> > lawyers could use it immediately. I estimated that it saved them
> > $150,000 the *first* year and at least $50,000 every year thereafter.
> > Get the right tool for the job.

Actually, you are in the midst of a totally plausible scenario: you are designing a db incrementally, letting your users test it and then modifying it - eventually it will reach a steady state, without further changes. Many people wish they could design a data warehouse this way.
What you are missing is a query tool capable of complex queries by endusers,
so you can test the design quickly, without spending a lot of time in sql. As your number of tables increase the tool should generate intersects and differences, not just joins. In addition, it should let you load and test the db with independent tables (no need to define/load referential integrity) by allowing for virtual, dynamic linking of the tables. That way your users can test queries and you can work on final design.
Some of our customers use vendor databases without referential integrity (use triggers instead); in order to do ad-hoc queries they use the tool to wire-in the db links virtually, so I know the concept works. I won't mention the tool, because this is not a sales seminar, but you can ask if you want. Received on Wed May 07 2003 - 20:00:30 CEST