These are really the basics of database design. I would argue that you should do these until you know when you shouldn't. That is, you should normalize to this level until you learn when and why to denormalize some things for performance, if that's ever even needed. I think it means "humble" as in not trying to teach anything complex or revolutionary.

> The advice to use NULL is usually harmful

The advice is to set NOT NULL if you think the field can't be null. That's valid, and a matter of encoding the schema to correctly match the data. Same with check values. Keep bad data out of the database wherever you can.

> and constraints are not high-performance

Then turn off constraint checking after you've built your schema and identified them as a performance problem. Don't optimize away your data integrity before you've even determined it's a problem.

If you actually don't care about your schema, just use a text field and throw whatever in it, or use a document store without any strict checking. If you're using SQL, presumably you're using it for a reason, and that's likely so you can take advantage of what it has to offer.

Hey thanks for clarifying it for the other user! I also agree with everything that you're saying, in this and other comments in the thread

The article actually advises setting fields to NOT NULL unless there's a specific reason to do otherwise.

And re constraints: eh, for most applications this feels like premature optimization. My usual approach is to include whatever constraints are easy to express, but also have the application not rely on the DB for enforcement. That way you get some extra safety checks that might catch bugs, but if they do become a bottleneck you can just drop them.

Not a DBA, just a software dev who's learned not to sacrifice safety for perf unless there's a clear, demonstrable need.

Please don't use databases that don't support transactional schema changes. You will hate everything about it.

Facebook, Google, and many other companies run massive MySQL deployments and are doing just fine.

They do, and obviously it is workable, but I think every big MySQL org ends up with a tool/workflow like gh-ost: https://github.com/github/gh-ost which have their own set of challenges, like not playing well with foreign keys.

Or the Percona tools, which support stuff like online schema change.

Big MySQL orgs are sharded, which greatly reduces the utility of foreign key constraints anyway.

Given unlimited VC money to burn, I could engineer a high-traffc SaaS running on a beowulf cluster of Juiceros.

Would that be a good idea? Maybe.

This is a silly argument. Facebook & Google have made massive investments into the source code of MySQL and have helped make massive operational improvements to it over the last decade. It's always glaringly obvious when people have no experience with something and then throw shade at it, like the obligatory Microsoft-bash whenever that topic comes up.

They also have massive engineering budgets.