Hi all,

Helen is going to tell us off for getting off topic but..

--- On Mon, 14/6/10, Aurimas Černius <aurimas@...> wrote:

From: Aurimas Černius <aurimas@...>
Subject: Re: [firebird-support] Re: How are foreign keys implemented, cascade update performance
To: firebird-support@yahoogroups.com
Date: Monday, 14 June, 2010, 8:55







 









Hi,



> From: "hvlad"<hvlad@...>

>>> One of my data models use natural keys that can change overtime. How are

> foreign keys and cascades implemented in the latest version of Firebird? Is it

> like in a REAL rdbms where the foreign key is actually a internal pointer to the

> referenced table and cascades are "instant" no matter how big the database

>>

>> Could you point us to the documentation to the such "REAL rdbms"

>> where your statement is confirmed ?

>>

>> Regards,

>> Vlad

> ------- End of Original Message -------

>

> Here you go:

>

> http://en.wikipedia.org/wiki/Codd's_12_rules

>

> Oh, but wait. Rules 1, 2, and 8 imply relational databases must use values, not

> pointers? Oops!



Do they really?



Rule 1: The information rule:

All information in the database is to be REPRESENTED ...



IMO, represented here means "show to user" or smth. Not "physically stored".



Rule 2: The guaranteed access rule:

... individual scalar value in the database must be LOGICALLY

ADDRESSABLE ...



IMO here "logically" means "you get value this way", not "value is

stored this way".



Rule 8: Physical data independence:



Clearly states, that APPLICATION should not depend on the way the data

is physically stored. Whether it's values or pointers, application

doesn't care, right?



BTW, I support values, not pointers.



--

Aurimas




The result of which is that it should not matter to anybody but vlad and co who are actually working on the db engine itself.

The decision for the programmer/designer is whether to use intelligent Primary Keys, which may change over time, or dumb ones that do not. I use dumb keys, so that I never have to cascade changes. Something about each bit of data only existing once...

regards
wb















[Non-text portions of this message have been removed]