Re: Why is database integrity so impopular ?

From: whileone <Sandy.Pittendrigh_at_gmail.com>
Date: Mon, 10 Nov 2008 08:06:06 -0800 (PST)
Message-ID: <a215b8b4-706d-48fd-8f90-24a37b3f721e_at_i24g2000prf.googlegroups.com>


On Oct 5, 11:30 am, eric.bouchardlefeb..._at_gmail.com wrote:
> Hello,
>
> When time comes to build transactional databases (as opposed to data
> wharehouses), I belong to the school that STRONGLY believe in
> normalizing data with high integrity mechanisms.  I know all the
> performance cons but IMHO, pros largely overwhelme.
>

Just to be difficult.....

This is now a long thread, with numerous well-crafted arguments exhaustively
defending good database design. But (largely for the sake of argument)
there are times when bad design is called for.

For large, well-funded projects, performance can always be purchased, usually for far less than the maintenance costs associated with
bad design.

But smaller, not-so-well funded systems are part of the bell curve too.
I wrote a web-based administration system for an "outfitters" organization once.
There were about 1000 licensed outfitters that needed to be tracked by a single-person administrator. So there was a private interface plus a
public one. The public interface was supposed to include a keyword search that combined outfitter location with arbitrary
combinations of attribute keywords like "elk hunting, fly fishing, walleye, pheasant" etc.

This organization had a limited budget and insisted on a cheap shared host server. Mysql queries with mulitiple named cursors
ran like lightning on my desktop linux box, but they ran like half- frozen molasses
on the overloaded shared host server.

But application code that did "string-like" over a long string of comma-separated
keywords worked, and it ran an order of magnitude faster (on the chintzy shared
host). Received on Mon Nov 10 2008 - 17:06:06 CET

Original text of this message