Question Backlog for Valentina mailing list.

[Ed Kleban]

> P.S will be great if you will ask Valentina specific questions on Valentina
> list.
>  
>Ruslan Zasukhin

Yes, You're right of course.  Here then, for the benefit of the list, is a
summary of some important things we've discussed recently.  I'll endeavor to
use the list more.

===========================
HOW MUCH RAM IS BEING USED
===========================
>> Is there a way to tell how much RAM V4RB is using for the database at any
>> given time?
> 
> Yes.
> 
>     Valentina.CacheSize
>
 
>> What is the affect of selecting various cache sizes when your database
>> resizes
>> in RAM only?
> 
> RAM DB do not use Cache at all.
>  

>> If you're running on MacOS X with virtual memory is there any good reason to
>> or not to just create a very large cache size?
> 
> For RAM database -- you can make it very small e.g. 1MB.
> 
> 
> Note, virtual RAM of OS is not very good for DB tasks.
> This is why each DBMS have own cache. It is more specific and effective

==========================================
PRE-HASHING OF UNIQUE VARCHAR FIELD VALUES
==========================================

>> Hi Ruslan,
>> 
>> I'm working with a unique varChar(504) field that will have lots of strings
>> of average length of say 30 chars.
>> Normally, if I were not using a database, I'd create us a hash table, such
>> as the Einhugur ObjectDictionary class to store and rapidly lookup strings.
>> I'm wondering if it would be worth while to create a hash of the string, say
>> using the RB variant.hash method, and store this in a parallel field of the
>> table containing the unique VarChar field, as a means of accelerating
>> lookups.   Binary Searches for the LongInt hash field would presumbably be
>> much faster than binary searches on the varChar field.   Does this sound
>> like a reasonable approach, or am I mising something?
> 
> Yes this is good idea, just note, with hash you can do searches only as
> 
>     WHERE fld = xxxx
> 
> But not 
> 
>     WHERE fld > xxx
> 
>
>> I'd still have to handle hash collisions of course if the text didn't
>> match... Which raises an interesting question.  If I knew which entry of the
>> index table for the hashfield was associated with the FindFirst call, then I
>> could just check varchar records identified by successive rows in the index
>> table for all matching hash values.  Is there a way to access the the index
>> table and use it in this manner?
> 
> Valentina 2.0 have for this method
> 
>     Vfield.ExistsValue( )
> 
> also
> 
>     Vfield.FindValue( )
> 
 

=======================================
WHAT IS MEANT BY "PARENT" AND "CHILD"?
=======================================


>>> Hi Ruslan,
>>> 
>>> I've read the description below about the difference between
>>> kFromParentToChild vs "from  child to parent" at least a dozen times and
>>> just can't figure it out.  Can you explain this in some other terms than
>>> parent/child or define what constitutes a parent vs a child in this context?
>>> I'm especially confused by the "(s)" in "record(s)" in that I can understand
>>> a parent record having multiple children by virtue of the the children
>>> having an ObjectPtr field that identifies the RecID of the Parent.  But I
>>> can't figure out what could possibly be meant by the implication that a
>>> child record might have more than one parent.
>>> 
>> Hi Ed,
>> 
>> * this should be used only for SELF-recursive links
>> 
>> * so image Table "Person".
>>     And Let it have link "Born To" of kind M : M (actually 2 : M)
>> 
>> * let you have record with RecID = 100 and it is person "John Johnson".
>>     this record have linked records.
>>     but look! This linked records are of 2 kinds: Parents and Childs.
>> 
>> So when you do 
>> 
>>     found = FindLink( 100, tblPerson, tblPerson,  ??? )
>> 
>> Who you want to find? Parents or Childs?
>> Last parameter allow you specify this.
>> 
>> P.S. Hmm... May be in fact we can make MORE functions to make things more
>> clean...
>> 
>>     FindLinked( recid, T1, T2 )
>> 
>>     FindLinkedRecursive( recid, T, inRecursionDirection  )
>> 
>> 
> 
>>>> RUSLAN:
>>>> Okay, let me try to explain.
>>>> 
>>>> We have recursive link. Recursive link can in  fact be written as:
>>>> 
>>>>         Table1 --- Link  --- Table1
>>>> 
>>>> So it similar to
>>>> 
>>>>         Table1 --- Link  --- Table2
>>>> 
>>>> Right?
>>>> 
>>>> We often write 1 : M link between 2 tables as:
>>>> 
>>>>         ParentTable  -- link -- ChildTable
>>>> 
>>>> Right?
>>>> 
>>>> So if you in brain unroll recursive link as above, you can think that LEFT
>>>> table is PARENT table, ad RIGHT table is CHILD table.
>>>> 
>>>> If take example with "Person" table and link "ParentOf"
>>>> 
>>>>         Person  ----- ParentOf ------ Person
>>>>         ^^^^^^                        ^^^^^
>>>>         parent                        child
>>>>  
>>> 
>>> Ok, now we're getting somewhere, and somewhere that makes some good
>>> intuitive sense.
>>> 
>>> Based on the above, would the following statements be true?
>>> 
>>> S1)  Creating a non-unique ObjectPtr field that contains recID values
>>> referring to records in the same table that contains the ObjectPtr field
>>> inherently defines a one to many relationship between a record indexed by a
>>> specific recID value, and all of the records that contain that recID value
>>> in their ObjectPtr field.
>> 
>> YES. The same correct for 2 different tables.
>>  
>>> S2)  If the ObjectPtr field referring to recId values in the same table that
>>> contains the field is also defined as having unique values, then the
>>> relationship established is inherently one to one.
>> 
>> YES. The same correct for 2 different tables.
>>  
>>> S3)  A one to many relationship can also be referred to as a "parent/child"
>>> relationship in which any one record associated with a given recID value is
>>> called the parent of all child records that contain that recID value in
>>> their ObjectPtr field.
>> 
>> YES
>>  
>>> If these are true, then these are the "missing" implicit information that
>>> experienced database users may take for granted, but which novices (or picky
>>> readers like myself) would appreciate seeing explicitly stated in the
>>> documentation.
>> 
>> AGREE
>>  
>>> This is still insufficient however, to explicitly explain what values of
>>> inRecursionDirection actually do.  Let me attempt to define those as well:
>> 
>> Yes, I think it needs add some pictures also
>>  
>>> S4) When calling aLink.FindLinked( inRecID, inTableA, inTableB,
>>> inRecursionDirection )  with inTableA = inTableB, then a value of
>>> inRecursionDirect = kFromParentToChild returns a VArraySet with the recID of
>>> zero, one, or many children records having inRecID as the value of their
>>> ObjectPtr field; whereas
>>  
>>> S5) inRecursionDirect = kFromChildToParent returns a VArraySet with at most
>>> a single parent record identified by the non-zero value in the ObjectPtr
>>> field value of the child record indexed by recID.  If the ObjectPtr field
>>> contains zero then the returned VArraySet is empty.
>> 
>> Right.
>> 
>
>Ok, great. Now I understand. :)
>
>> Only not complete yet:
>> 
>> * you talk only about ObjectPtr always.
>> 
>> * Valentina 2 have also link - FOREIGN KEY.
>>     it is similar to ObjectPtr by nature. It is a field.
>
>Yes, certainly.  And in a full discussion it should be mentioned as well.  But
of course it's the ObjectPtr aspect that offers the great performance
>and appeal to me and which I intend to use, so it was on the top of my mind in
trying to understand this.
>
>> * Valentina 2 also have new link -- BbinaryLink. This is not a field at all.
>> 
>> Methods of Vlink class work for ALL link kinds. So it needs write text in
>> general form.
>> 
>
>Yes. I understand and agree.  First I had to understand what it did.  I could
write something that would serve all cases now.   I very much like the concept
of the Vlink; making the links be an instantiated abstraction is very cool.   I
think however that there may be a better way of presenting the description of
Vlinks to the reader.  It's a little difficult for me to rationalize them being
a third kind of link rather than a separate abstraction for referring to a link
using a mechanism that is essentially the same as the ObjectPtr approach if you
look underneath the covers -- at least I presume that's the case.  It's just a
matter of where you keep track of that extra ObjectPtr column for book-keeping
purposes.
>
>Thanks for the feedback.
>
>--Ed

============================================
PROPOSED NEW SYNTAXES FOR PARENT-CHILD LINKS
============================================


>>>> RUSLAN:
>>>> P.S. Hmm... May be in fact we can make MORE functions to make things more
>>>> clean...
>>>> 
>>>>     FindLinked( recid, T1, T2 )
>>>>     FindLinkedRecursive( recid, T, inRecursionDirection  )
>>> 
>>> An interesting idea, but sheds [no] light on the question I have.
>> 
>> Hmm, or even better idea!
>> It looks more natural as
>> 
>>   set = TableA.FindLinkedTo( ThisRecID, ByThisLink, InTableB );
>> 
>> // and for recursive links:
>> 
>>         TableA.FindChildsOf( ThisRcID, ByThisLink )
>>         TableA.FindParentsOf( ThisRcID, ByThisLink )
>> 
>> Problem is that somebody can use this for non-recursive ...
>> May be its possible to prevent this ... It needs to think about this .
> 
> Yes, I certainly like this form in which the ObjectPtr field is identified
> explicitly as an argument much better, and this syntax does make it more
> clear.  I'll have to leave the Table validation question for you to consider.
> 
> The correct grammar would be "FindChildrenOf" rather than "FindChildsOf".
> 
>