I believe that both approaches make sense at appropriate app layers, but the key is the ability to handle data structure evolution. Being able to change data s

I believe that both approaches make sense at appropriate app layers, but the key is the ability to handle data structure evolution. Being able to change data schema with little overhead allows to operate on a less normalized structure and adjust it more frequently. Meanwhile, designing a highly normalized schema and implementing complicated queries takes time and still doesn’t make it entirely proof against the future. Nitpick: UI-agnostic data schema example is what conventionally is referred to as normalized—closer to a theoretical canonical form, independent of query convenience at runtime. The other example, where tasks are child nodes of a project, would be the denormalized one.