Re: Why is database integrity so impopular ?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 31 Oct 2008 20:07:20 -0300
Message-ID: <490b8fae$0$5474$9a566e8b_at_news.aliant.net>

paul c wrote:

> patrick61z_at_yahoo.com wrote:
> 

>> On Oct 6, 12:51 pm, Daniel Pitts
>> <newsgroup.spamfil..._at_virtualinfinity.net> wrote:
>>
>>> 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.
>>>> It amazes me, though, how many systems rely on the application to
>>>> manage data integrity. I work as IT director for a large-size
>>>> manufacturer and *none* of our applications use integrity. And I am
>>>> talking here of ERP and other mission-critical systems.
>>>> In fact, I had rarely open a database properly normalized and
>>>> inforced ... and I have been working with databases for over 10 years,
>>>> mostly in sectors where lack of integrity can result in dramatic
>>>> consequences.
>>>> What is wrong with modern DB design approaches? And what's the point
>>>> of using a big relational DB without the benefits of integrity and
>>>> normalization?
>>>> Thank you,
>>>> EBL
>>>
>>> I think that part of the problem is DB design and Application design are
>>> really different types of abstraction. For application programmers,
>>> dealing with DB constraints is tedious.
>>>
>>> The truth is that whenever your "Application" calls for persistence, it
>>> is no longer just an "Application"; it has become a "System". System
>>> design is a higher level abstraction.
>>>
>>> Moving from Application design to System design is /almost/ a natural
>>> progression, and many engineers traverse the barrier without ever
>>> realizing and without learning the other aspects of System design. This
>>> includes learning proper DB design.
>>>
>>> I admit that I fell into that category for some time. My background has
>>> been Application design, but I've started to appreciate the concept of
>>> constraints at ever level of the System. I even sometimes wish that the
>>> DB could do more validation than it does, even if it makes things a
>>> little more "tedious". In this case, tedious just means the hard
>>> problem is already solved.
>>>
>>> --
>>> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
>>
>> I think that relational database theory is too limitting for some
>> applications. I believe that the modern database needs to be split
>> into component parts so that not everyone has to be saddled with the
>> relational part.

> 
> No offence, but I think you are way off-base to associate any version of 
> the rm as being aimed at transactions in any way, neither theory (that's 
> being charitable as much of the transaction writing has no formal 
> theory) has much connection with other, at least so far.  Suspect such 
> thought has to do with marketing bumpf from various product publicizers, 
> indoctrination seems to be involved.  Still, I must say that a 
> declarative model of some version of transaction interests me though 
> I've never seen anybody try to explain one.  But so far, you haven't 
> even hinted at that notion  as far as I can tell.  I think the happy 
> cirsumstance is all-important when trying to transpose one technique to 
> a new purpose and the first insight must be to recognize the circumstance.

[Quoted] Paul, please, who cares about ignorant opinions that have been asserted with no support whatsoever? So the guy boldly steps forward to show off his ignorance. Do you really have to reply to it? Received on Sat Nov 01 2008 - 00:07:20 CET