SSDT diagrams
Database documentation is as paramount as it gets in terms of database development.
SSDT should include a robust diagram experience with the ability to comment tables and fields.
Frédéric FOREST
shared this idea
4 comments
-
Mark Duff
commented
This same issue is spread among multiple comment threads, which dilutes our true fury over the arbitrary removal of SSMS diagrams (which should also have been in VS long ago). How many of we who have paid for it for years requested this? What exactly was the Use Case?
Where is the sense of urgency in the midst of effectively destroying decades of architectural drawings caused by simply not including something that's always worked fine the the past?
-
Michael Fischer
commented
I second that. It's my most missed features. We're coming from a development approach where we designed the databases in a case tool as ER diagrams and then generated db generation scripts. While the SSDT and dacpac way of development has HUGE advantages the overview diagrams give you is absolutely necessary. Now the former diagrams and the schema grow apart. SSDT should definitely be the place where we create and check in diagrams.
-
Gus
commented
I agree, and actually diagrams should be in both places, ssms and vs
-
JediSQL
commented
I agree. If diagrams are being removed from SSMS because diagrams are a "developer thing," then moving it to SSDT in the developer's Visual Studio tool makes a lot of sense.
I would like any new tool to read & write existing sys.diagrams data. I have hundreds of diagrams in dozens of database per my organization's documentation policy. I really like the existing diagrams being connected to the database so that column changes in tables do not require someone to manually refresh the diagrams to keep them up to date.
If we don't get something that can, at least, present sys.diagrams-based diagrams, then upgrading to SQL Server 2019 will result in Microsoft capriciously throwing away all that documentation I have generated over the last 16 years.