Binary links Re: Question Backlog for Valentina mailing list.

[Ed Kleban]

On 11/16/05 1:20 PM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 11/16/05 9:04 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>> Yeah, well, you're making a convert out of me on that approach pretty
>> quickly.  I've just finished a first pass at re-diagramming the database I'm
>> designing using Binary Links instead of ObjectPtr fields.  It's amazing!
>> 
>> One question that has come up, is that if I want to associate some type of a
>> typeCode that is a small byte constant that identifies the type of an item,
>> and I need to access that typeCode all the time for items to do select case
>> statements and such, and I also want to keep an anciallary table with
>> additional information about that typeCode, then should I:
> 
> That is the problem. BinaryLink cannot have associated information.
> For this it needs to use old good MM tables.
> 
> I still cannot find way how to add this association...effectively.
> 
> 
>> 1) Both create a Binary link between item and their typeInfo records, where
>> the recID is inherently a representation for the typeCd, and then
>> additionally allocate a byte TypeCode field in the item records, under the
>> theory that I can grab the typeCode very fast most of the time, and then do
>> an indexed lookup by record ID when I occasionally need the extra type
>> info...
>> 
>> or
>> 
>> 2) Punt the darn typeCode byte in the item record because binary links are
>> so blazingly fast in the many to 1 direction that that having a typeCode
>> byte would be no faster and just make for messy double book keeping.
> 
> If you can put it into ONE table then I think good
>  
> And keep in mind, right now M to One is not ideal speed.

So you've said. But you haven't really explained why or what speed is to be
gained by optimizing.

> 
>> or 
>> 
>> 3) Right idea, but if you really want the blazingly fast connect from the
>> typeCode in the item record to the typeInfo record then use a full Ulong for
>> the typeCode as an OffsetPtr because Valentina will optimize accesses and be
>> more efficient using the ObjectPtr than converting from a byte index.

Now that I understand, and understand why, that performance of a BinaryLink
is the same as an ObjectPtr I'd probably go this 3rd route.  It would
require more space for the ObjectPtr than the Byte field, but I'd end up
with optimal performance for all possible operations.  And when you
implement BytePtr in Valentina 3 I'll get the wasted space back :)