Recently I came across a case where we designed a normalised database schema. According to common principles, this was the right way to do it. The design is sufficiently flexible and robust to handle many use-cases.

The issue is that we don’t need to query data in the common ways, i.e. we normally need to pull out everything rather than individual pieces. That means we are using larger queries than may be necessary due to various relations etc. It seems that in this instance, a document database would have served us better.

That said, the “pull out everything” approach is a crutch for legacy design choices. The project is a partial rewrite which uses a prior project as a library (when it was written as an application). We grab all the data, chuck it in to the old system as a black box, then get results out wholesale.

We could write a data model which enable use to make better use of the normalised approach. That constitutes a much larger rewrite. I suppose this is more a case of: which approach is more achievable for our team.

Nevertheless, in the short term, using a schema or database which is better suited to our current needs would have served us better. It’d be easier to slot the “document db to normalised schema” changes into the full code rewrite approach anyway.