Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)
Date: 21 May 2004 13:21:24 -0700
Message-ID: <4b45d3ad.0405211221.396176d6_at_posting.google.com>
> > Among other things, the difference in normalization between the
> > implementations is quite different.
>
> It should not matter HOW my implementation generates the report.
It does matter because a less generic and unnormalized implementation will cause more problems or even fail under a broader scope.
Here is another example. Suppose the user enters 'john' in tbl_thing and then enters 'john' in other tables. Later he tries to change 'john' to 'johnny' in tbl_thing. I tried, but I cant because of constraints to keep redundant data in multiple tables from becoming unsynchronized (UPDATE statement conflicted with COL REF constraint 'FK_types_thing_0D'. This conflict occured in db 'Test', table, 'types', col 'thing'. Statement terminated.)
In XDb1, user can change 'john' to 'johnny' and the report runs as
before.
Using data itself to link redundant data is a non-generic solution.
Received on Fri May 21 2004 - 22:21:24 CEST