Re: [LIU Comp Sci] Need tutoring on Relational Calculus

From: Eric <eric_at_deptj.eu>
Date: Fri, 2 Jan 2015 21:44:24 +0000
Message-ID: <slrnmae49o.d9l.eric_at_bruno.deptj.eu>


On 2015-01-02, ruben <nowhere_at_nowhere.nor> wrote:
> On Wed, 31 Dec 2014 17:23:12 -0500, James K. Lowden wrote:
>
>> I can think of no way in which "normalization is a failure".
>
> well, think harder about it then because just this morning its failure
> was facing me, eye to eye when some expert normalized our database and
> exhausted the system resources and dropped productivity through the
> floor, killing a good part of my new year.

So,

  1. You have put a major change into production without proper testing.
  2. You have put a risky change into production without scheduling people to pick up the pieces (if any) - their new year may be killed, but they should be expecting it.
  3. Does anyone know what the expert was supposed to be achieving?
  4. Does the expert understand database design and have a tried and tested recipe for normalization?
  5. Is it possible that you database design, which worked well enough (FSVO), was a very bad place to start normalizing from?

These are all about failure, but they are _not_ a failure of normalization itself.

> http://lambda-the-ultimate.org/node/3762

A reference to a post (on a site which is essentially comp.lang.theory) which is a reference to a paper which is mostly a literature review, contains the author's own bad examples (he doesn't get what a library system is about), and is, if you forgive it those things, not totally dissimilar to a paraphrase of the things Mr Lowden said that you cut out of your response.

> The first problem with normalization is the failure to focus on the right
> problem. This is true about many database modeling problems, BTW.

This is a common failure of the use of normalization, and other methods and tools, in just about any area. In all cases, essentially a human failure, not a failure of a theory.

> the central problem with databases is, and always will be, the need for
> rapid, accurate, and reliable transactions.

A requirement, not a problem, central or otherwise.

Eric

-- 
ms fnd in a lbry
Received on Fri Jan 02 2015 - 22:44:24 CET

Original text of this message