October 25, 2025 at 12:00 am
Comments posted to this topic are about the item Why Data Modelling Still Matters - More Than Ever
October 26, 2025 at 12:10 am
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
October 26, 2025 at 3:20 pm
Thank you for this article, John. I won't directly address your question but would like to bring up some topics you discussed and how it affected me this week. (Past week, as I am writing this Sunday morning.)
I am a developer who has been given the responsibility of being one of our GitHub Administrators. With that comes things like writing good GitHub Actions/Workflows. (And hopefully passing that knowledge onto other developers.) We have a major application we're working on. Periodically there will be a major release. We had a major release this week, which didn't go well. These releases are done at night, when we've gotten permission from the users to do the release overnight, so the users our out of the system until the next day. Prior to the release I hadn't heard whether we were going to do the release, because the users hadn't given their permission. So, when my day ended, I left. But unbeknownst to me, the release had been scheduled, only I wasn't invited to it. The release had some major problems, as the production database schema was not in sync with the UAT database schema. The contract developer who had written hundreds of lines of SQL code to update production tried to apply the changes, but it failed and screwed things up badly. The deployment to the application went fine, but it was designed to work with the new database schema. From my point of view, the meltdown resulted from multiple causes.
First, it has been a practice since time immemorial to believe that all releases will fail. In fact, this is dogma. Because we all know that all releases will fail, not enough effort is put into making the applications/databases better to try and prevent failures. And because the expectation is that all releases will fail, the most important thing is to have a rollback in place. So, problems went wrong, people (especially the managers on the call) panicked and demanded that they roll back to the previous version of the software and database, rather than diagnose what the root cause is (that is never done). I was finally notified that a failed deployment was in progress an hour after it had started, so I joined to help.
Secondly, every department works without collaborating with any other department. So, the DBAs are never consulted nor used. The developers/contractors write all SQL scripts to effect the changes and run them.
Other contributing factors were involved, but the two previous ones are the most important factors. Because the go to solution, when a release fails, is to roll back the deployment of database and/or application, we never have a chance to determine what the root cause(s) are, it's always GET IT WORKING NOW!!!!!!!!!!! Even though we could have worked on the problem because we had the whole night, that is never done.
I've been in this position for several years now, and I've seen this pattern done multiple times. Not all deployments fail, but a high percentage of them do. The insistence that all departments maintain their turf at all costs and never collaborate with any other departments denies us the ability to learn from each other. And always assuming that a release will fail has led developers/contractors to not be as careful as they could be. Ultimately, we don't know why the deployment failed and the conditions no longer exist to evaluate what caused the failure. So, it now becomes a thought experiment, for the next attempt.
I've learned that there are some poor habits which have become institutionalized, and I believe will require certain people to eventually leave, in order to remedy the solution. I've tried for years to make suggestions, concerning software architecture, with no success.
Kindest Regards, Rod Connect with me on LinkedIn.
October 27, 2025 at 11:36 pm
I retired in 2021 and figured it was a good time. Database design was one of my favorite tasks and it appeared that no one was designing databases. I agree with the arguments for how a well designed database can make for a smaller, more efficient and easily expanded database. I worked in database design for 20 years and we never developed in a pure waterfall approach. It was an iterative waterfall everywhere I worked. I still believe that the Conceptual Database Design should be completed as part of the requirements gathering phase. But I am not sure formal requirements documents are created on a project today.
I am not sure about the Redgate Data Modeler but I know many of their tools are very useful. What makes a database modeler useful is being able to create a Conceptual Model, easily convert it to a Logical Model and then easily generate the DDL to produce the physical database, all in one tool. Additionally it should be possible to detect database creep and sync the model to the physical database.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply