In article <3d358213.1273624344_at_news.globix.com>, you said (and I quote):
> It is assumed that (bad) Database Design could be the worst bottleneck
> in database performace. Curious in kinds of 'really bad' designs
> people have encountered and what hardships they had to go though to
> modify the schema or work around it to accomodate a customer.
There are so many I don't even know where to start.
I'll try a few, just on the very narrow field of db design; there is also
application architecture and application design itself:
- Design an entire schema with not a single PK or FK or declarative
referential integrity of ANY kind.
- Design a humongous schema in the vain belief that it is "easier to
administer" than various small ones.
- Excessive normalization, with virtually no use whatsoever of the
concept of sub-typing.
- Failure to use the best features of each database for the sake of
dubious "portability".
- Failure to design a schema that matches the transaction flow of the
application. With the result that multiple db transactions are needed to
accomplish one single business transaction.
- Failure to adequately separate time-series data from OLTP or daily
processing data.
- Failure to resolve and simplify arcs. These can easily degenerate into
multiple UNIONs of lengthy joins which grow exponentially in complexity.
- Failure to adequately separate the discipline of logical db design from
the physical db design.
- Failure to produce access path lengths and multiple hierarchy entry
points.
- Failure to provide for easy data location with minimal joins.
and the list grows...
--
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam
Received on Thu Jul 18 2002 - 07:57:29 CDT