DOGE employees don't understand the basics of SQL

There's so much partisan noise about DOGE going around -- At this point, I don't know what to believe anymore. Elon lies constantly, abuses employees, backstabs partners, and is probably a racist; At the same time, his companies have created seemingly impossible/fantastic technologies/tools that have changed the world forever.

Is DOGE a genuine effort at desperately needed reforms to save America from bankruptcy? Is it a secret plot to take full control of the federal government like a dictator's coup? Is it a mix of both at the same time (ie; recent Saudi and Chinese 'anti-corruption' campaigns)?

What should I believe?

A sledgehammer doesn't need to be able to turn a screw. Perhaps states might take advantage of this, but the incompetency of toadies at technology won't impact their competency at wreaking destruction.

My read of this post is it's just this guy's word vs doge's. Doge says they allow nulls for TAS, author says they don't. I'm pretty sure in the author's example, though, the payment _could_ be created with a NULL vendor, as I'm pretty sure NULLABLE is default for int in PostgresSQL. Depending on the scenario, this may be "bad" or it may be intentional. What would really matter is "does the system actually transfer funds or cut checks without a TAS". In ERPs I work with, a payment without a vendor is allowed in a draft state, but to get an actual check, you need a vendor.

Most of these types of articles I'd imagine will be right but there is some truth in the argument that "Ah, you see, the system is merely so complicated and murky that you can't understand it!" is damning too

When seeing the approach to how Elon/DOGE applied themselves to air traffic control after the incidents, I'm not falling into the Gell-Mann amnesia effect. This group is just incompetent and going to re-learn all the mistakes within each domain that led to industry getting to where it has through a series of hard won lessons.

When a foreign key field is left empty, that implies that no foreign key relationship was claimed. By definition a primary key cannot be no. But a foreign key, which is a representation of another table's primary key, can be null. It merely means that no foreign key relationship is claimed.

I'm glad I don't work with this guy. I've had co-workers who routinely talk to me in this way, treating me as an infant so they could feel superior. I wonder if he'll regret this post going viral.

Just wait until they come across some mainframes and need to figure out JCL.

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.

What his team has seemingly uncovered is not waste. It's a little thing I like to call, "Extremely routine database architecture."

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.

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:

  select * -- for brevity
  from payment p
  join vendor v on p.vendor_id = v.vendor_id

To get the payment rows with null vendor_id, the export would have to be done using an outer (left) join like so:

  select * -- for brevity
  from payment p
  LEFT join vendor v on p.vendor_id = v.vendor_id

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.

In his example he even has it as nullable:

  CREATE TABLE payment (
    payment_id SERIAL PRIMARY KEY,
    vendor_id INT REFERENCES vendor(vendor_id),
    payment_date DATE NOT NULL
  );

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.

Now regarding Musk's tweet:

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.

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:

  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

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.

Q: Elon Musk, What did you get done this week?

A: Demonstrated my "crack" team is incompetent and lacks basic skills. Also broke a lot of stuff.

Does anyone really believe Elon Musk doesn’t understand basic RDBMS theory? Seems like troll-bait to me.

It could be that, a big misunderstanding of normal database design, or it could be a legit error. No one has offered direct evidence of either case. What I'll say is that working in legacy industries with legacy data, all bets are off as to whether anything is well posed. My first company's "database" was a folder of 100 excel files. OP is making a massive assumption that the federal government is using modern SQL database design principles in this specific application, or a modern database at all.