<Fred Brooks quote here> I worry we are skipping over an important design step by outsourcing our schema. What tables and columns are involved in a database i

<Fred Brooks quote here> I worry we are skipping over an important design step by outsourcing our schema. What tables and columns are involved in a database is just as much the business owners concern as it is the developers concern. There aren't a whole lot of situations where the developers can invent a fantasy schema that just happens to fit perfectly with everyone else's understanding of the business. There are also seriously powerful, multi-spectral dragons lurking for those who think they can lock their nasty schema behind an API and throw away the key. In my experience, things tend to go a lot more smoothly when non-technical stakeholders can look at a sample excel workbook demonstrating the schema and agree with its contents. Every nasty workaround I have ever had to deal with at scale could ultimately be boiled down to a bad database schema or model that was poorly designed relative to the problem domain. How you arrange your data is the most fundamental part of any software. This all gets back to information theory and hard math at a certain level. The instructions are just a means to an end. All of that said, we usually have to start somewhere and having a library of schema samples to review can serve as a powerful kickstart in the right direction. Just make sure you aren't inventing this in a vacuum relative to the business at hand.