Binary links Re: Question Backlog for Valentina mailing list.

Ruslan Zasukhin sunshine at public.kherson.ua
Wed Nov 16 23:36:27 CST 2005


On 11/16/05 11:25 PM, "Ed Kleban" <Ed at Kleban.com> wrote:

>>>     Question 1: Would use of a UShort field here for 16-bit encoding
>>>     of RecID actually be slower than use of an ObjectPtr?
>> 
>> NO.
>> 
>> And we have think about giving to developer such ability to specify type of
>> ObjectPtr. This bring few problems:
>>     - mistake of developer
>>     - type of ObjectPtr different, then how right correct code?
>>  
>> And honestly was no time to go so deeply.
> 
> Well, I suppose you could have 3 types of ObjectPtr:  LongPtr, ShortPtr,
> BytePtr.   Furthermore, you could put a "MaxRecords" constraint on tables
> that you intended index by ShortPtr or BytePtr.  You already have constraint
> checking to support record additions in the case of a Unique field for
> example.  A "too many records" check would be very fast.

GOOD IDEA!

> Similarly, if the
> user did indeed blow it, worst case is that the indexes would wrap modulo
> word or byte boundaries and refer to the wrong record.  Which is
> unfortunate, but not particularly dangerous in that it could point to a
> non-existant record that has not been allocated.
> 
> In fact, this would be no worse of an error than would result if a user
> claimed that a binary link was 1->M or M->1 or 1->1 when it was in fact
> M->M.  If they supply the wrong assertions, they'll get the wrong results as
> the system endeavors to optimize search on their behalf.

No no.  if you have specify for Link 1 : M for example,
Then Valentina will watch for integrity and refuse wrong operations.

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]




More information about the Valentina mailing list