VStudio - synopsis of my findings to date regarding Valentina RecID

Barry G. Sumpter BarrySum at BigPond.Net.AU
Fri Jun 1 22:31:07 CDT 2007


OK, this is pretty much for my notes and doesn't need to be commented on.

A synopsis of my findings to date regarding Valentina RecID.
Written in my words for my reference from my, possibly limited, 
background as a developer using MSAccess and MSSQL.

Each Valentina record already has a built in: 
  Unique RecID as a Primary Key that Auto increments.
    So we don't need to build our own additional field 
    as a Primary key that Auto Increments.

For 1 to Many Relationships
  Instead of building a ForeignKey for each link pointing to a ForeignTables
Primary Key
    we build an ObjectPtr for each link that points to the ForeignTables
RecID.
    NOTE: Don't confuse yourself attempting to use:
          An additional ForeignKey to point to the RecID in the
ForeignTable.
          You can, but the Valentina ObjectPtr is smaller and faster.

For Many to Many Relationships
  Instead of building an indexed key table for each link
  we build an indexed BinaryLink key table for each link.

Note: RecIDs are recovered after deletion.
  If you need access to a history db then be careful how you add recovered
RecIDs to history DB

  Example:
    Start with Fresh DB on January 1.
    Add Live Data.
    Archive Live data to history db with RecIDs on January 31.
    Add Live Data.
    Delete live data recs from February 1 to Feb 15.
    Resequence/recover RecID recovering RecIDs from deletes on February 15.
    Add live Data (using available RecID recovered from deletes) thru Feb 28

    Archive Live data to history db with RecIDs on Feb 28.
      WARNING: Be careful how you Archive Live data to history db.
               As the Recovered RecIDs from Feb 15 live data 
               will point to existing archived recs from Jan 31 Archive.





More information about the Valentina-studio mailing list