How Database ID Patterns Work
There has been an interesting theory spreading across the election integrity universe that we felt needed some grounding in reality. It has to do with recognizing patterns, or the absence of patterns, within voter ID’s across a state. The primary thing to remember when deciding whether claims like these have merit is Occam’s Razor: The simplest explanation is usually the correct one.
The claim centers around the idea that there is a hidden algorithm within state voter ID’s that prove there is some type of fraud taking place. We love a good conspiracy as much as anybody, but there are enough factually identifiable flaws within our voting systems that wild ideas like this detract from making substantive changes. We don’t want to discourage this type of investigation and the inquisitiveness that goes along with it, we just prefer to not make inflammatory claims based on an assumption without doing our research first.
There seems to be a basic misunderstanding of how ID assignment in a working database is handled, in particular one that has been subject to complete data migrations between older and newer systems.
Imagine a county has a filing cabinet with folders for every registered voter, numbered 1, 2, 3, 4… all the way up, in the order people registered over the years.
Now the county decides to move everything into a new statewide computer system. To do that, they take every single existing folder and load them in, one by one, giving each one a new ID number in order 1, 2, 3, 4… This happens all at once, during the move. So naturally, those original records will have IDs that look neat and sequential. Then the next county that joined the system loads their records, but the first county already used 1, 2, 3, 4, so the second county has to use 5, 6, 7, 8. Eventually a little later a new person registers to vote in the first county, this new voter is assigned number 9 because 5 is already taken, and the relation between county and ID number begins to splinter.
The database doesn’t stop after the first record sets are moved to the new system. New people register, people move and update their address, names get corrected. Those new entries get added after the move, so their ID numbers come from a different point in the sequence and they don’t fit the original pattern, because they were never part of the original move.
That’s not a glitch or fraud. That’s exactly how it’s supposed to work.
What this person has “discovered” is the difference between:
- Records that existed before the system was built (sequential, neat)
- Records that were added or changed after (later numbers, different pattern)
Below is an explanation of how ID’s are assigned and how the relation between sequential ID’s can shift over time and how the source of these claims discovered in a very, very, roundabout way that these voter databases are functioning exactly as expected.
When a database is first built, or an old database is migrated into a new system, all existing records are imported at once and given clean, sequential IDs. Any records added or changed after that point will naturally fall outside the original pattern because they were created at a different time. It is how every modern database works, no flaw, hidden algorithm, or evidence of fraud on it's own.
Old system: records exist with legacy IDs
All records imported into the new system at once
Real life continues, new registrations and changes are added
Company starts with one salesperson: Alex
Two more salespeople join: Beth & Carlos
Store launches with an existing product catalog
New products and seasonal items are added over time