DR (Detail Record) Domain
A DR (Detail Record) domain is a single, unjoined child table. This is
the simplest approach to indexing because the table is indexed by itself
as a stand-alone table. Joins to other tables are accomplished through
Multi-finds.
- A DR domain child table's Omnidex ID is a 32-bit Integer ID.
- A 32-bit ID list is smaller than the 64-bit ID list that is necessary
with a prejoined child table.
- A 32-bit compare is much faster than a 64-bit compare that is necessary
with a prejoined child table.
- Bitmap Indexing can be used on a DR domain child table.
- Joins from the DR child table to other tables will access the database,
possibly slowing performance.
Similar to a parent table, a child table can be in its own domain. You
need not prejoin a child table to a parent. This creates a DR domain.
In this situation, the domain is named after the child table it contains.
MDK indexes on a child table qualify child rows.
Unjoined child tables require less Omnidex indexing maintenance. Joining
from those tables to another table during qualifications, however, may
be slower and may require more system resources.
Multi-find performance has been greatly improved and may be the preferred
join method over an RS domain, depending on the database. See the Sorted
Multi-Find section for information on which to choose.
Hybrid DR Domain
Hybrid DR is a variation of a multi-domain child. It provides you with
the ability to index a child in two ways:
- as a DR domain
- in an SI domain without specifying child indexes
You would install this domain combination when the table contains millions
of records or when you want to do a bitmap join.
The benefits to indexing the child table in this manner are:
- ease of indexing. There is no need to install a separate set of keyword
indexes on the child for each domain where the child was linked. As
a result, you do not have the costs discussed in the previous section.
- faster compares. It allows 32-bit compares in the child domain versus
64-bit compares with Record Specific. This is typically faster unless
you are on a 64-bit machine.
- smaller ODXID lists. Record Specific uses 8 bytes per ID; an unjoined
child uses 4 bytes per ID.
- smaller indexes because the index just stores the child row IDs.
The following image shows an example of the domains created using this
installation strategy:
To index the child table, ORDERS, in this way, you install the child
as follows :
Table? Orders
To index this table in any parent domains enter the name of the field
linking it to its parent
Link field 1:customer_no
Table will be indexed in the domain of CUSTOMERS.
 No keys are
declared in that child in that domain.
Link field 2:product_no
Table will be indexed in the domain of PRODUCTS.
No keys are
declared in that child in that domain.
Link field 3:$DR
Table will be indexed in its own domain.
This causes
the child to be indexed as an unjoined child.
Link field 4://
Enter fields for CUSTOMERS domain:
Keyword field://
Enter fields for PRODUCTS domain:
Keyword field://
Enter fields for ORDERS domain:
Enter all
the fields you want installed in the child’s DR.
Keyword field:order_date
Keyword field:status
Keyword field://
Table name?//
When completed, the installation builds the Record Specific ID cross
reference portion of the SI domain’s index file, but no indexes
for the child table itself.
The Record Specific ID cross reference is built because $DR was entered
when the child was installed. This is used in bitmap joins.
Top
|
