Benefits of declaring foreign key links.

[Ed Kleban]

On 12/23/05 2:26 PM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/23/05 6:25 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>>>> The other reason I am tempted to do this is that I see the advantage of
>>>> having these links explicitly declared so that Valentina Studio will show
>>>> the related links in the Data Browser.
>>> 
>>> Right. 
>>> 
>>> Hmm, not right. IF you have also create FOREIGN KEY on your byte fields,
>>> then Vstudio also will show links.
>> 
>> Yes. I'm aware of that.  And the reason behind these questions is to better
>> understand whether I should keep the UByte and UShort fields and continue to
>> use them as pointers manually along with declaring them as links so that VS
>> will see and use them....
>> 
>> Or whether there is some additional benefit to instead using ObjectPtr
>> fields instead because of some performance gain I am unaware of at the cost
>> of using a lot more storage.
>>  
>> So far my conclusion based on what I've read here is that there is no real
>> advantage to using an ObjectPtr over using a smaller-sized UByte or UShort
>> rid reference field AS IF it were a BytePtr or ShortPtr in my code, and
>> declaring it to be a foreign key link with the RecId of the parent table
>> being the key field.
>> 
>> That make sense?
> 
> Hard to say. 
> 
> I think can exists db where small win,
> and can exists case when ObjectPtr win.
> 
> You can do benchmarks self
> 
> Actually in DB I meet this always. Exists always few  cases and few
> algorithms, each win in its are.
> 

No, I don't think so.  One of two things is the case here.  Either:

a) You can tell me why ObjectPtr has some inherent performance advantage
over the use of a Byte or Short as if it were an object ptr because you have
some specific optimization built into the API calls that take advantage of
an ObjectPtr. [And there is special case handling for ObjectPtrs such as
automtically treating them as unique indexed for example]

or 

b) There is no inherent performance advantage of using an ObjectPtr over say
a Ulong as if it were an ObjectPtr, and therefore in the case of a Byte,
Ushort, or Umedium  there are storage benefits of declaring what would
otherwise be an ObjectPtr field as Byte or Ushort or Ulong and manually
treating it as if it were an ObjectPtr.

And I believe that in the next email reply you conclude that (b) is the
correct answer to this.