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