Handling large numbers of mapping table entries

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. 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 !  &#x2a;&#x7c;adam@domain.com&#x7c;&#x2a;&#x7c;tcp_local    $Y &#x2a;&#x7c;betty@domain.com&#x7c;&#x2a;&#x7c;tcp_local  $Y ! ...etc... ! ! Users not allowed to send to Internet !  &#x2a;&#x7c;norman@domain.com&#x7c;&#x2a;&#x7c;tcp_local  $NInternet$ access$ not$ permitted &#x2a;&#x7c;opal@domain.com&#x7c;&#x2a;&#x7c;tcp_local   $NInternet$ access$ not$ permitted ! ...etc... ! ! Users allowed to receive from the Internet !  tcp_&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;adam@domain.com        $Y tcp_&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;betty@domain.com      $Y ! ...etc... ! ! Users not allowed to receive from the Internet !  tcp_&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;norman@domain.com      $NInternet$ e-mail$ not$ accepted tcp_&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;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&#x7c;adam@domain.com   $Y SEND&#x7c;betty@domain.com  $Y ! ...etc... SEND&#x7c;norman@domain.com $NInternet$ access$ not$ permitted SEND&#x7c;opal@domain.com   $NInternet$ access$ not$ permitted ! ...etc... RECV&#x7c;adam@domain.com   $Y RECV&#x7c;betty@domain.com  $Y ! ...etc... RECV&#x7c;norman@domain.com $NInternet$ e-mail$ not$ accepted RECV&#x7c;opal@domain.com   $NInternet$ e-mail$ not$ accepted with an  mapping table of: ORIG_SEND_ACCESS ! Check if may send to Internet !  &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;tcp_local       $C${SEND&#x7c;$1}$E ! ! Check if may receive from Internet !  tcp_&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;           $C${RECV&#x7c;$3}$E Here the use of the arbitrary strings  and    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   and    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:
 * Mapping tables
 * General database
 * MTA performance tuning
 * Recipient access mapping tables
 * Mapping entry templates
 * Mapping entry templates
 * Mapping table format