Considerations for rate table size

Rate table size is an important factor to consider when designing rate tables. Rate tables have no inherent size limit within PolicyCenter, however very large tables (100,000+ rows, for example) present management issues during development and promotion. For large tables consider rate lookup, import/export, and business maintenance requirements.

To simplify lookup, you can split large tables into smaller tables, reducing the number of rows. For example, you can split a large table based on parameter domains. A vehicle table can be broken up by manufacturer or by year. You can create a rate routine function to select the correct table. When using functions, have the function do Rating Management lookup, not direct database lookup, to ensure that you access the correct version of the rate book.

Large rate tables with multiple factors can be normalized by splitting into two or more tables. See Considerations for single or multiple factor rate tables.

If you cannot split a very large table with 100,000+ rows, then consider crating a custom physical table. The DefaultRateFactorRow entity is very generic, but is inefficient with regards to storage, especially when exported to XML.

Another approach is the move the data out of a rate table and implement it as a system table. Design the system table with effective and expiration date columns. Similar to a rate book lookup, the lookup to system tables uses the reference dates. This approach requires custom configuration. Once you have the data in the external table, you can use utility functions in rate routines to lookup the tables.