Re: Generate a CRUD matrix

From: Ed Prochak <edprochak_at_adelphia.net>
Date: Tue, 04 Mar 2003 08:46:46 GMT
Message-ID: <3E646BA0.2050308@adelphia.net>

David FitzGerald wrote:
> DA Morgan <damorgan_at_exesolutions.com> wrote in message
>
>

>>You can audit insert, update, and delete (triggers and audit). But
>>select? You really don't want to go there.

>
>
> I think you misunderstand slightly... I don't want to see every
> select, insert, undate or delte -- all I want to know is if that table
> was accessed whatsoever during a given session.
>
> This is the scenario... I have a database which has loads of redundant
> tables, but I don't know which ones. I want to run a functional test
> and see what tables it needs to have populated. Once I have gone
> through all my functional tests I can drop tables which have had no
> activity on them whatsoever.
>
> Because of the nature of the application, most of the table accesses
> are select's. So, if I could see that tables a, b, and d all had
> select's run against them, but table c did not I could then infer that
> table c is redundant.
>
> Many thanks,
>
> David.

And you are absolutely positively 1000% sure the functional tests trigger every table access used by the application? WOW

Also, have you considered the scenerio where:   table A and B are both accessed, but they contain identical (redundant) data? (you might be able to replace table B with VIEW B.)

Testing cannot find all the flaws. Maybe yours will find most of what you need. But be prepared for the errors that show up a few weeks after you remove the redundant tables. Keep backup copies to put 'em back.

(I sure hope this is not in production.)

-- 
Ed Prochak
running: http://www.faqs.org/faqs/running-faq/
family:  http://web.magicinterface.com/~collins
--
"Two roads diverged in a wood and I
I took the one less travelled by
and that has made all the difference."
robert frost

Received on Tue Mar 04 2003 - 02:46:46 CST