Re: Database Design nightmares...

Nuno Souto <nsouto_at_optushome.com.au.nospam> wrote in message news:<3d36bcdd$0$16942$afc38c87_at_news.optusnet.com.au>...
> 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.

Nuno lists fairly mild examples...

The worst cases I saw usually combined 2 features:

1. Complete lack of understanding of relational databases. From here follows:
2. Complete denormalization of data. Including such triffles as using the same column for different goals, making one column containing concatenated values, i.e. not following even 1NF rules. Also software which assumed some order in the tables. People were REALLY surprised when they didn't get results in that order.

> 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...
Received on Thu Jul 18 2002 - 16:39:36 CDT