Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

Neo wrote:

>>>Although brown appears three times in the script, XDb1 normalizes the
>>>second two by making them references to the first one. There is only
>>>one brown in XDb1's db. Using RM#1 or #2, brown is stored three
>>>separate times.
>>
>>Would that mean that if John's name is brown, it would be stored in
>>the same place as the color brown? 

>>And would that mean that if the UI designer wanted to change all browns 
>>to umber as part of a UI redesign, that it would change John's name?

So, are you saying that if Christopher Browne's name was misspelled in the original input as "Brown", and then corrected somehow, Alice Brown's name would become Alice Browne (note spelling) in any reports generated?

What is the mechanism for correcting such (normally encountered) situations?

(Hint: In a "normal" database structure, it would mean replacing one attribute in C. Browne's record. As I understand your scheme, if you did it right, it would mean searching the data-store for any "things" which contained the string "Browne", if found, creating a reference to that in C. Browne's *new* record, and replacing the record. If not found, creating a thing with the content "Browne", and then replacing C. Browne's record with the new reference. Seems like an awful lot of work to change a misspelling.)

To take this to the point of silliness, why doesn't the string "brown" refer to the characters 'b', 'r', 'o', 'w', 'n' as 5 different references which could each be stored in the data-store just once. After all 'b' is a thing, isn't it?

/Reductio ad absurdum./

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch