On Jun 23, 4:47 pm, "Frank Swarbrick" <Frank.Swarbr...@[EMAIL PROTECTED]
>
wrote:
> >>> On 6/23/2008 at 10:16 AM, in message
>
> <485F77F7.6F0F.008...@[EMAIL PROTECTED]
>,
>
> Frank Swarbrick<Frank.Swarbr...@[EMAIL PROTECTED]
> wrote:
> > Thanks to all who responded. I new feel quite confidant in shooting
this
> > idea down.
> > :-)
>
> Interesting. Here's a page my co-worker is using to justify his
position:http://www.dbforums.com/showthread.php?t=1619660
>
> Frank
I just encountered a situation which shows a part of the problem. This
system uses a codes table and a duplicate had been entered
inadvertently. This caused my application to operate incorrectly as
its SELECT INTO failed. So a data change broke my code.
Which reminds me of a maxim I like and try to follow:
It's not how well it works when it works that matters. It's how well
it works when it doesn't work that matters.
So until a programming or data error happens, EAV (which includes
OTLT) seems to work fine. But later, during maintenance (code or data
changes) when a duplicate or other error is introduced into the
system, things start deteriorating. The value of DBMS enforced
integrity constraints begins to ****ne in the maintenance phase of the
system. EAV can never come close in large systems. When the original
chief programmer leaves, which system would you rather reverse
engineer. ('cause I will bet you, the EAV design do***ent is
nonexistent or ,due to the nature of EAV, does not include the real
information your want about how the system really works.)
Ed
|
