It is easy to see the advantages of a ObjectPtr + RecID solution over the FK + ID of the Relational model.

Let's look at the following picture. The top two tables show a solution with FOREIGN KEY and bottom Tables show a solution with ObjectPtr.

Note that in the second case there is no need for the KEY field and its index. If you have, for example, a million records in the table, and the KEY field of ULONG type, then using ObjectPtr-links you can save on disk:

1 million * 4 bytes = 4MB              -- size of the field data.
((4 + 4) * 1 million) * 1.5 = 12 MB    -- the average size of the index.

total = 20 MB.

ObjectPtr-link is a more flexible structure than Foreign Key.

Really, when you specify FK between T1 and T2 you link some field of T2 to field of T1. Both fields should have the same type. In contrast, when you create an ObjectPtr field, you specify only Target Table T1.

What's the difference? The difference is that in the first case you cannot easily change/delete the PK field. It is used in the FK-object. In the second case you do not have such limitations. You got more freedom.

Since Valentina Tables have the “RecID” Field with unique RecID values for each record, in most cases developers do not have to care about an artifcaial Primary Key for this Table. Also, there is no need to care about an auto-increment feature.

We get advantage not only in the size of disk files but also in speed. Let's consider a few examples.

• Usually, the DBMS keeps records on pages files. A Record can change its location on the page, or even move to another page. This raises a problem: How to create index on some field of table? What should be used as internal record pointer? We do not want to update all indexes of the table if a record changes its location.

The solution is that there exists a primary index for the table. It sets correspondence between PK ID and Internal Row ID, which depend on DBMS implementaion.

All rest indexes of this Table are named Secondary, and they use PK value as pointer of a record.

It is easy to see that after you have found some record using the secondary index, you need to jump into primary index, find here the direct pointer to the record, and only then you can locate the record in the table.

• Valentina can use RecID values to be direct pointers to the record. There is no such object as a Primary Index. Secondary Indexes use RecID to point a record.

Join operation based on ObjectPtr link also usualy win comparing to Foreign Key link.

One of the main reasons here is that algorithms of FK need to operate on index of PK and Column of FK field or its index. ObjectPtr-based algorithms do not need and do not use PK index. This way,

• we save time on PK Index load - it is ZERO
• and we save RAM on PK Index - it is ZERO,
• and we save time because no need search this PK index to find physical location of record - it iz ZERO.

• RecID Field
• ObjectPtr Field
• ObjectPtr Link