[dingaling]

I encountered this in a personal project in the past week.

The ideal, normalized schema would be slow and awkward for manual insertions on a daily basis, which I felt would deter me and hence undermine the project.

The not-quite-normalized version would be much quicker and more intuitive for me to keep up-to-date, so I talked myself into it.

In the future I can always write a stored proc to process the less-normalized data into idealized tables, and use the original tables solely for importing the data.

Despite that reassurance it was remarkably difficult to accept that doing the 'wrong thing' programmatically was the 'right thing' in a project scope.

[tmaly]

I took the exact opposite approach in a personal project. In my professional experience I have seen this exact same pattern with stored procedures use to hide poorly designed tables. After time, more entropy occurs in the system. Being able to change things comes to a crawl as you have duplicate data due to the initial poor schema design.

Many of the current databases like Postgresql let you create views. And the performance even on a smaller machine is quite good. So if you stick to a normalized schema and build views, it will pay dividends later on.

[hinkley]

I think outside perspectives from other disciplines can help here.

I garden, and before that I tried and failed at bonsai for quite some time. With landscaping it's good to have a five year plan, because everything keeps changing when you're not looking, and if you tried to do everything you wanted all at once you'd hurt yourself and/or kill the plant(s).

I also played Go for a long while, and I found parallels with the philosophies in refactoring. One of the big things in Go is that there are always fifteen things you could be doing but some have contingencies, and among the others you can't win unless you prioritize these options better than the other guy. You know what moves you will make, and when the time is right you will make the move, and the next and the next almost without thinking, because there are patterns just like in software. But right now this other move has more upside so you are doing that instead.

[jacobparker]

Depending on your database (I'm assuming some manner of SQL) you could create a view that is denormalized and supports SELECT/INSERT/UPDATE/DELETE for human query UX.

[zgryw]

It always helps to have someone to bounce those ideas off.