Handling large numbers of mapping table entries

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


Sites that use very large numbers of entries in mapping tables should consider organizing their mapping tables to have a few generic wildcarded entries that call out to the general database for the specific lookups. It is much more efficient to have a few mapping table entries calling out to the general database for specific lookups than to have huge numbers of entries directly in the mapping table. (As a rule of thumb, certainly by the time a mapping table has reached about one hundred entries, it is worthwhile to consider whether the number of individual entries could be reduced by consolidating into more general entries that call out to the general database to check specific data.)

One case in particular is that some sites like to have per user controls on who can send and receive Internet e-mail. Such controls are conveniently implemented using a recipient access mapping table such as ORIG_SEND_ACCESS. For such uses, efficiency and performance can be greatly improved by storing the bulk of the specific information (e.g., specific addresses) in the general database with mapping table entries structured to call out appropriately to the general database.

For instance, consider a mapping table:


ORIG_SEND_ACCESS

! Users allowed to send to Internet
!
  *|adam@domain.com|*|tcp_local    $Y
  *|betty@domain.com|*|tcp_local   $Y
! ...etc...
!
! Users not allowed to send to Internet
!
  *|norman@domain.com|*|tcp_local  $NInternet$ access$ not$ permitted
  *|opal@domain.com|*|tcp_local    $NInternet$ access$ not$ permitted
! ...etc...
!
! Users allowed to receive from the Internet
!
  tcp_*|*|*|adam@domain.com        $Y
  tcp_*|*|*|betty@domain.com       $Y
! ...etc...
!
! Users not allowed to receive from the Internet
!
  tcp_*|*|*|norman@domain.com      $NInternet$ e-mail$ not$ accepted
  tcp_*|*|*|opal@domain.com        $NInternet$ e-mail$ not$ accepted
! ...etc...


Rather than using such a mapping table with each user individually entered into the table, a more efficient setup (much more efficient if hundreds or thousands of user entries are involved) would be as follows. Use general database entries of, say:


SEND|adam@domain.com    $Y
SEND|betty@domain.com   $Y
! ...etc...
SEND|norman@domain.com  $NInternet$ access$ not$ permitted
SEND|opal@domain.com    $NInternet$ access$ not$ permitted
! ...etc...
RECV|adam@domain.com    $Y
RECV|betty@domain.com   $Y
! ...etc...
RECV|norman@domain.com  $NInternet$ e-mail$ not$ accepted
RECV|opal@domain.com    $NInternet$ e-mail$ not$ accepted

with an ORIG_SEND_ACCESS mapping table of:


ORIG_SEND_ACCESS

! Check if may send to Internet
!
  *|*|*|tcp_local       $C${SEND|$1}$E
!
! Check if may receive from Internet
!
  tcp_*|*|*|*           $C${RECV|$3}$E

Here the use of the arbitrary strings SEND| and RECV| in the general database left hand sides (and hence in the general database probes generated by the mapping table) provides a way to distinguish between the two sorts of probes being made. The wrapping of the general database probes with the $C and $E metacharacters, as shown, is typical of mapping table callouts to the general database; see the General database substitutions topic, under Mapping entry templates for an additional discussion. For a discussion of the general database itself -- where it is located and how to build it---see General database.

The above example showed a case of simple mapping table probes getting checked against general database entries. Mapping tables with much more complex probes can also benefit from use of the general database.


See also: