Is Data Modeling Common? Recently, I had a few questions on database modeling. One was posted in the SQL Server Central forums, and a customer asked about ERD tooling on the same day. This came shortly after Redgate acquired Vertabelo (now Redgate Data Modeler). This stood out to me as very rarely in the last few years have I found people consulting and updating a diagram while performing database development. When I started as a developer and needed to update a database, I had to first update a diagram that was stored in ErWin. We had a dedicated computer (back when we went to an office every day) where the software was run and any developer could us this to update the diagram with proposed changes. Back then, we had to get another peer to sign off on changes before making them, and the peer was supposed to go check the diagram for the change before approving it. That's only if they thought your change made sense and conformed to our standards (naming, design, etc.). Over the last decade or so, it seems there haven't been a lot of common tools for building diagrams in the Microsoft space. The SSMS Database Diagrams haven't been the easiest to use and I rarely see people consult it. I loved ER/Studio, but it and ErWin were very expensive and outside the budget for most groups. There have been a lot of smaller online tools, but I don't see a lot of consensus for which ones people like. There are DbSchema and SqlDBM, among others. I see various blogs, like this one, that recommend different tools, but the uptake seems to be low in many organizations. I hope Redgate can make data modeling more common with Redgate Data Modeler (coming soon to the Toolbelt). My question for you is do you still maintain and use database diagrams for development? Or is this a somewhat lost art? Is it not necessary or useful for you? Do you wish your development teams did this to ensure a more cohesive and consistent model? I used to like having a diagram because it a) forced me to slow down and rethink things a bit as I made updates and b) let me see where there were dependencies. One of the reasons SQL Dependency Tracker exists is that I asked Redgate to extract the dependency tree from SQL Compare to allow me to see it separately. This would allow me to know what other objects might need to be changed if I refactored ObjectA. I found that to be a great "picklist" of things to check during database development. I don't know how many people these days perform data modeling, but I do know a lot who don't spend much time thinking about the changes they make. I fear data modeling has become a bit of a lost art, which saddens me. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums | 
