Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)
Date: Sat, 22 May 2004 21:43:34 +0200
Message-ID: <fnava0piumbcdbrhfq06fnvjtdcl20lcpt_at_4ax.com>
On 22 May 2004 11:48:57 -0700, Neo wrote:
>> > change 'john' to 'johnny' ... cant because of constraints...
>>
>> I had forgotten to include DRI actions when I posted the
>> script for my implementation. Everywhere I wrote "references things", I
>> should have written "references things on update cascade on delete
>> cascade". I'm perfectly willing to supply the code for the trigger
>> if necessary to convince you.
>
>No need to supply the code. I accept that the proper DRI would change
>'john' to 'johnny' in all remaining tables that used 'john' and I
>accept that the chance of future programmers forgetting to add the
>necessary DRIs for new related tables is very low.
>
>> >Using data itself to link redundant data is a non-generic solution.
>>
>> Huh? Please elaborate.
>
>Suppose your things table allows two things to have the same name, ie
>'john' and 'john' (to approximate the genericness of the db created
>with XDb1). In things table, each 'john' is a different record (and
>hopefully there are enough other attributes to distinguish them; if
>not, an id column might be added).
>
>Now suppose you have a 2nd table called hierarchies and wish to link
>its parent column with rows from things table. In this case, the data
>(ie 'john') could not be used to perform the link, because it would be
>ambigious. Thus, using data itself to link redundant data is a
>non-generic solution.
Hi Neo,
If the requirements were such that two things might have the same name, my design would have been different. If the requirements are that two things can have the same name but only if they are of different classes, I could have used thing+class as primary key for the things table; this would also have introduced extra columns in related tables. Or I could have chosen to use a system-generated ID instead. In a real applications, such decisions are made so as to get the best performance for typical usage patterns.
If the requirements had even allowed two things of the same class to share the same name (e.g. two persons named 'john'), I would have asked for more information, because an RDBMS requires a possibility to identify each individual row in a table. (I don't know if XDb1 has such a requirement; I hope it does, because there is not much use in storing data about things if you have no way of knowing WHICH thing you're storing data about - if there are two persons named john in my office, what use is the statement 'john is aged 35' to me?)
Best, Hugo
-- (Remove _NO_ and _SPAM_ to get my e-mail address)Received on Sat May 22 2004 - 21:43:34 CEST
