On migrations, there's a .Net tool called Grate that I tend to use for schema migrations... I don't use all the features, but it works well... using a migration stack in a repository for deployments and a similar tool is IMO more reliable than magic comparison tools or hand migrations in practice. You should defensively write your migrations as much as possible so that re-runs are relatively safe, though the tool hel…
> Even with indexes, joins are costly, especially under load at scale with millions of simultaneous users. You can avoid a lot of this by simply having that sub-table information inside a JSON field with the row in question. They’re really not that bad. Even on large-ish tables (hundreds of millions of rows), the typical query time I see for a query with 1-2 inner joins is 1-2 msec. That can of course vary with resul…
There was absolutely zero advantage in how the data was structured in that case (auto classifieds website).
That's not to say that database normalization and modest level of joins is always bad... it's just something that can go too far, and holds things back even more in certain environments. FWIW, I started bundling child data in XML before JSON was a thing in highly controlled environments where any schema change was very difficult and required approvals through several groups in a large banking org.
That JSON is fairly well supported today only makes this an easier and better option IMO. Again, sometimes, but enough times to make note of.