Bad database design on most systems seems to hurt more in terms of the cost of maintenance and enhancements than it does in terms of performance. I have found that bad design begets further bad design. The concept seems to be that if it was already done a certain way it's ok to continue to do it that way. Even if the way it was done is continually bad. For example, when doing enhancements I frequently find that developers just want to add tables and columns and not worry about normalization. This is easier for them, but every time you do this the model gets more complex. People frequently come and go from projects and as new people role on they are forced to work on an ever increasingly complex data model that few people seem to really understand. I have found that people are happy to complain about how bad a data model is than do the same things that made the data model bad in the first place and thereby make it worse.
The hard part with making people see this is that they don't see the consequences of it as they are developing the module. The consequences come out in maintenance and enhancement phase. However, if all they ever did in their career was work with bad design then they won't know its bad and will be used to it.
- Original message --------------
> Michael,
>
> This RAD approach is interesting. What has happened is that most
> systems are so small either in the number of users or the amount of data
> that proper database design really doesn't matter any more. The
> hardware is so strong(ie: fast) that a bad database design just does not
> have the impact that it would have if there were thousands of users or
> terabytes of data.
>
--
http://www.freelists.org/webpage/oracle-l
Received on Thu May 26 2005 - 11:50:23 CDT
