Designate/Blueprints/Records Table Redesign

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

Having one monolithic RecordSets table and 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 record_id, 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 the tables below for more detail.

Database Schema Changes
The existing Recordset table and Records table will become obsolete and be replaced with new tables for each record type.

Comments & Discussion

 * 1) Could someone else verify that the Data Type, Length and Nullable fields are correct in the various records tables?