Redesign Recordsets and Records Tables

Currently, there is only one Records table for all the different record types. This blueprint proposes to subdivide that tables into a Record table per record type.

Having one monolithic Records table for all record types can become problematic as the size of the table grows. If any modifications need to be made, for example, adding a column, the entire table would have to be locked and it could take a long time to update a table with millions of records. In addition, if a table gets too large, it has to be sharded, which involves writing a lot of code to know which shard to call for which records. On the other hand, joins across tables are not a problem, as long as the indexing is done correctly. In addition, having a table per record type is a proven DNS database design as some companies have already implemented it in this fashion and have millions of records.

Most of the information that is currently in the Records table will be consolidated into the RecordSet table. The Records table for each type will only contain the recordset id and the unique data for that particular record type. For instance, the A_Record table will contain the recordset id and the IPv4 address. The MX_Record table will contain the recordset id and the FQDN for the mail server and its preference value. See the full specification for more detail.