Re: Demo: Modelling Cost of Travel Paths Between Towns
Date: Sat, 20 Nov 2004 00:34:30 +0100
Message-ID: <shvsp0p2mgscs665kl19cid58mc9re8dua_at_4ax.com>
On 17 Nov 2004 12:16:22 -0800, Neo wrote:
(snip)
>The problem is how the above things are actually represented in the
>db, and in particular how they are linked and the resulting
>consequences on flexibility and not as much on the ability to avoid
>data corruption.
Hi Neo,
Are you writing what I think you are writing? Do you think that the consequences on flexibility are more important than the ability to avoid data corruption? Or am I simply misunderstanding you?
If you truly think that flexibility is more important than maintaining integrity, then this would be the right moment to just agree that we will always disagree on this. In my opinion, a database that doesn't maintain integrity is worth nothing.
> In RM, John in the two relations are linked by the
>data-dependent string 'John'.
No, in RM they are linked by whatever the developer, designer or DBA designates as primary key. Many people would choose a surrogate key, others prefer the natural key, yet others pick the option that's best suited to the situation.
>Instead of saying redundant data leads to corruption, I should have
>been saying, with synchronization mechanisms turned off, a way to
>check for redundant data is to modify one John (ie to Johnn) and see
>if the data becomes unsynchronized. If data does become unsynchronized
>then one has redundant data.
"With synchronization mechanisms turned off" - but who would do that and why would anyone do that? This is like saying that a bike is better than a car because you can still jump off before going down a cliff if the steering wheel is removed.
I'm sure that if I'd use a hex editor to turn some internal mechanisms of XDb off, it would corrupt data as well.
Please, Neo - let's try to keep the discussion sane, shall we?
(snip)
> they both lacked flexibility to
>handle certain cases. For example neither solution could handle
>multiple things with the same name.
That's because the requirements were changed afterwards. And (as pointed out by others in this thread), the RM is better equipped for changing the model without having to rewrite the code than other models.
(snip)
>> > > > In your example, you stored john (a fact) twice.
>> > >
>> > > You call 'john' a fact?????
>> >
>> > Yes, 'john' is a fact. In fact, a, b, c ... are facts.
>>
>> All my arguments to the contrary are here:
>> http://dictionary.reference.com/search?q=fact
>
>I will accept that 'john' or 'j' may not meet your or Webster's
>definition of a fact, which is irrelevant
(snip)
If you consider the dictionary meaning of terms used in these discussions irrelevant, it becomes really impossible to continue the discussion. As you know, I'm Dutch - English is not my native language. I often have to rely on dictionaries to understand what others write and to make sure that I write what I want to convey. This goes from the presumption that the other participants in this group use the same words with the same meaning.
Best, Hugo
-- (Remove _NO_ and _SPAM_ to get my e-mail address)Received on Sat Nov 20 2004 - 00:34:30 CET