![rw-book-cover](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F48146907-55ee-4ef1-aa11-ecd917ed6615_1414x772.png) ## Metadata - Author: [[joel-labes|Joel Labes]] - Full Title:: I Unknowingly Built a (Bad) Semantic Layer in 2018 - Category:: #🗞️Articles - Document Tags:: [[Data modeling|Data Modeling]], - URL:: https://roundup.getdbt.com/p/i-unknowingly-built-a-bad-semantic - Finished date:: [[2023-08-22]] ## Highlights Instead of addressing a root cause: requests for change take a long time to resolve. > Since requests for change would take a long time to resolve and be a painful experience for all involved, some enterprising staff started finding workarounds. For example, they would export multiple existing reports to CSV, stick them together with VLOOKUPs > [4](https://roundup.getdbt.com/p/i-unknowingly-built-a-bad-semantic#footnote-4-136183821) > , and then work from that until the data became too stale to be useful. ([View Highlight](https://read.readwise.io/read/01h8cf1hm6qpwfx4vxct0cp7k3)) > Each entity had its own grain, and since this all the data was precalculated and stored – instead of truly understanding joins – we had to limit what other information could be brought through. ([View Highlight](https://read.readwise.io/read/01h8cf3qp7gsa1sa0ezp3qgycp)) > I described this change as splitting out our operational reports from our analytical reports. ([View Highlight](https://read.readwise.io/read/01h8cf5p4xr1k6c58gee8c9xgj)) > Looking back at it, the difference was not actually operational vs analytical, but that these reports were built **with entities at their heart instead of a specific use case**, so downstream users could build for many more use cases without our involvement ([View Highlight](https://read.readwise.io/read/01h8cf8qd79rct4w4rvjw50kb0))