Redesign Recordsets and Records Tables

Registered by Betsy Luzader on 2014-03-10

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.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Medium
Drafter:
Betsy Luzader
Direction:
Approved
Assignee:
Betsy Luzader
Definition:
Approved
Series goal:
None
Implementation:
Informational Informational
Milestone target:
None
Started by
Graham Hayes on 2016-06-17
Completed by
Graham Hayes on 2016-06-17

Related branches

Sprints

Whiteboard

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.