[bob1029]

> Fixed schemas are good.

I recall getting into an argument recently (perhaps on HN) wherein the central thesis for why SQL is bad is because the schema is "difficult" to change relative to a document store or other no-SQL abstraction.

If you don't have a clear idea of what the representative SQL schema might be for your problem or business (say, within ~80%+ certainty), one may argue you should not be writing any software until you've further clarified things with business stakeholders.

I strongly believe that virtually all evil which emerges from practical software engineering comes out of this "flexible schema" bullshit. If the business is certain of the shape of their problem, there is almost certainly a fixed schema that can accommodate. There are very few problem domains which cannot be coaxed into a strict SQL schema.

[totalhack]

There are also ways to add some flexibility into a "fixed" schema when you need it. Entity-attribute-value tables, views, JSON columns (as a last resort), or a semantic layer like https://github.com/totalhack/zillion

[bob1029]

> JSON columns (as a last resort)

This is the design-time escape hatch for me. The remaining 20% space of unknowns can usually be dealt with here. As long as the most critical tables, relations & properties have been set in stone, I would find it reasonable to allow a "ExtendedPropertiesJson" column in limited areas of the schema.

Over time, these JSON blobs should be refactored into the schema as features become more stable.

The key is to have a solid relational model as the foundation. You cannot really do it the other way around.

[Scarbutt]

Business requirements change over time, specially at the beginning, you may have 80% certainty of the schema today but not in four months.