<i>In this tweet, Elon Musk (and DOGE?) have come to the conclusion that $4.7T in spending was blank, "making traceability almost impossible." This is because the TAS is used in many tables, and is used as a primary key in others tables using a foreign key constraint.<p>What his team has seemingly uncovered is not waste. It's a little thing I like to call, "Extremely routine database architecture."<p>This maintains referential integrity between the two tables. It works exactly the same way with TAS in the IRS database. I checked for myself. It's not optional.</i><p>The last sentence, "It's not optional," is the crux of the argument. When he says it's not optional, I assume he means the payment.vendor_id FK is defined as NOT NULL. When doing exports like he is referencing, if it's an (inner) join, it wouldn't export the nulls. Here is an example of an inner join that if used doing an export wouldn't export the NULL vendor_id payment rows:<p><pre><code> select * -- for brevity
from payment p
join vendor v on p.vendor_id = v.vendor_id
</code></pre>
To get the payment rows with null vendor_id, the export would have to be done using an outer (left) join like so:<p><pre><code> select * -- for brevity
from payment p
LEFT join vendor v on p.vendor_id = v.vendor_id
</code></pre>
We don't know how it's exported, so if the author only has access to the exports and not the actual schema, he wouldn't know either.<p>In his example he even has it as nullable:<p><pre><code> CREATE TABLE payment (
payment_id SERIAL PRIMARY KEY,
vendor_id INT REFERENCES vendor(vendor_id),
payment_date DATE NOT NULL
);
</code></pre>
Notice the payment_date is defined as explicitly NOT NULL while the vendor_id (the FK he is talking about) is not defined as NOT NULL (implicitly NULL). If the vendor_id is NULL, that would represent a payment with no vendor.<p>Now regarding Musk's tweet:<p><i>In the Federal Government, the TAS field was optional for ~$4.7 Trillion in payments and was often left blank, making traceability almost impossible. As of Saturday, this is now a required field, increasing insight into where money is actually going.</i><p>To make an existing NULL field required (NOT NULL) in a RDBMS database, you have to first populate it with something. When it's a FK like vendor_id, you have to populate it with a vendor_id that exists the vendor table. With the amount of rows I would imagine is in that database, this is no easy feat. To make it required, the would have to:<p><pre><code> 1. Update each NULL row to the actual vendor it was supposed to be (probably impossible to figure this out)
2. Update each NULL row to a new vendor_id named "Unknown" or something to that effect.
3. Update the application(s) that write to the database to make it required, leaving it NULL in the database.
4. Maybe something else
</code></pre>
One more thing, all this assumes the system is using an RDBMS. If it's a mainframe or something (which it very well might be), all bets are off.