Re: Why is database integrity so impopular ?
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