>>But the people i am working with are not considering the restructuring of
>>the database. They are even thinking of expanding it by adding new modules.
>>
>>Please can someone advise me, or tell me what to do, what may be the
>>consequences
>>
>>
>>
>
>My advice is to not go to them with the "we need to totally reengineer the
>schema for the next 6 months so that we have the same functionality we have
>now" approach. Instead figure out what the next module they want to add is
>and what parts of the system it will touch upon and then see about
>reengineering those particular parts of the schema. The bit by bit approach
>should get them to the same end game with stalling development for the next
>few months. Make sure to make use of views and stored procedures to help
>keep backwards compatibility where you can't convince people to do code
>modifications. HTH.
>
>
>
I second this advice. Remember that (to business people) bad database
design is not a critical problem unless it interferes with critical
business goals. What I would do is to lay low and do what they tell you
for several months, making your own observations about how the database
actually works and keeping track of potential data design fixes (i.e.,
combine these tables, replace this column with a foreign key to that
one, etc).
If the database design is as bad as you say, in not too long you will
come to a situation that would be best handled with normalized data.
Then bring it up, saying, "We could re-structure the data to look like
this so that X query could be computed with a single select with minimal
rewriting of module A and a few queries in module B."
At that point, your employers will hopefully say, "Oh, yes, that's a
very clever solution." Then you implement your fix and take the credit
for this. Ideally, over time, you will build up a reputation as a
problem solver and gain more responsibility for database design and thus
have more ability to fix the underlying problems.
Regards,
Paul Tillotson
