Do you use Database Diagrams?

Using Database Diagrams?

Visual Studio Team Edition for DB Pros: The What, The Why, The How — Wed, 21 Feb 2007 03:49:57 GMT

Hey folks, please check out this post from Mairead . If you've ever used the Database Diagramming feature

re: Do you use Database Diagrams?

Mark Wisecarver — Wed, 21 Feb 2007 04:02:27 GMT

I probably don't use them in VS 2005 as they were intended but they are a great resource for a sort of Post-it notes, even for screen captures, they can illustrate relationships better than I can with notes.

Let us know how you use database diagrams

Musing on Database Development — Wed, 21 Feb 2007 04:07:05 GMT

Mairead from the Data Dude product team has a post looking for feedback on database diagram usage. If

re: Do you use Database Diagrams?

Ian Morley — Wed, 21 Feb 2007 04:47:53 GMT

I find ORM diagrams are much more useful than ER diagrams. I use these a lot to communicate/validate entities and relationships with clients.

re: Do you use Database Diagrams?

KenJ — Wed, 21 Feb 2007 06:32:10 GMT

For maintaining existing systems (for which nobody has created/maintained a physical model), I use the SQL Server diagrams to quickly get a visual of how a group of tables relate to each other. I've also been known to reverse engineer these into a third party modeling tool for the same purpose.

For new development, I use a third party modeling tool so I can both keep a useful visual reference and generate the DDL statements to create the database, as modeled.

I'm looking forward to an integrated modeling tool for DBPro that can be synchronized with the scripts in the database project (either push model changes into the project DDL scripts or pull changes from the DDL scripts into the model).

re: Do you use Database Diagrams?

Yitzhak Khabinsky — Wed, 21 Feb 2007 08:44:32 GMT

I am badly missing relationships editing capabilities in the SQL Server 2005 environment. Database Diagram has just a delete option. Beyond that when relationship is based on the multiple columns it is not easy to see it.

re: Do you use Database Diagrams?

cra451 — Wed, 21 Feb 2007 08:51:45 GMT

We like to use them but they are no help on my current project. Access allows a diagram to work against a view SQL2005 doesnt. My jons happen to be constraints becouse of this. and Data Dude doesnt read constraints as Joins when doing testing etc...

Hope this helps

re: Do you use Database Diagrams?

Andy Mackie — Wed, 21 Feb 2007 12:02:28 GMT

What would I like ?

At a minimum - produce a physical data model. Ideally, also support conceptual/logical models that map to physical models.

Generate SQL scripts from model.

Check into version control, in a format that allows comparison of current/previous models.

Reverse engineer existing DB to a model

Multi-database support (SQL Server, Oracle, DB2, ...)

For large models - partition them for different areas of the system.

Generate documentation/reports from the model.

etc. etc.

Something along the lines of Sybase PowerDesigner :-)

http://www.sybase.com/detail?id=1039951

(I never did like ERWin - but it's a similar sort of idea)

re: Do you use Database Diagrams?

Marcus vR — Wed, 21 Feb 2007 18:12:51 GMT

I agree with much which is outlined above by Andie Mackie.

I have used ER Win, it's current owners have allowed it to die on the vine, but some of it's functionality is important.

I think the functionality to handle different databases like Oracle, DB2 etc is a seperate piece to be addressed later, if at all. This requirement uses a logical model as a converter between these different systems and from which you choose to create a physical model. When this situation does arise such a tool is vital, but i believe and have found this is not the most common situation. As mostly, even in businesses that have multiple different DBs, any particular model is associated with only one of them.

I feel the important feature is for a tool that can reverse engineer or syncronise into a model, and can permit the model to be used from a variety of perspectives or model types, for documentation, for high level views of big environments. This functionality is soreley needed, and the tool should integrate with Compare and Syncronisation tools.

Do you use Database Diagrams?

Visual Studio for Database Professionals (aka Datadude) — Wed, 21 Feb 2007 21:27:13 GMT

If so you should read and give feedback on this post: http://blogs.msdn.com/mairead/archive/2007/02/21/do-you-use-database-diagrams.asp

Database Diagrams, Feedback and Usage

Euan Garden's BLOG — Wed, 21 Feb 2007 21:49:57 GMT

Database Diagrams in SQL Server 2005 and VS 2005 were one of the more *ahem* controversial issues. If

re: Do you use Database Diagrams?

DRBuckingham — Wed, 21 Feb 2007 23:10:09 GMT

Because of their limited usefulness, I currently tend to use them only for reverse-engineering an existing (undocumented/unmodeled) database, typically through SSMS rather than VS.

I would definitely prefer that it be more of a real modeling tool, at minimum the level of which Visio can provide (round-tripping, scripting changes, type/subtype, etc.). If it would be greate if it supported logical versus physical layers, as well as supporting user-defined extended properties.

I think it would be a short leap from there to be able to create HTML and/or CHM files for documenting the database in a nicely formatted manner.

re: Do you use Database Diagrams?

Chris — Wed, 21 Feb 2007 23:14:51 GMT

Database diagrams are great for just designing your db schemas and then having the tables right there in the database. Visio documents can be a pain to maintain synchronisation.

So, for a start, the features that database diagrams used to have in SQL 2000 and no longer exist in SQL 2005 would be nice! For example, right click on a table and view the rows in it.

re: Do you use Database Diagrams?

Rachit Patel — Wed, 21 Feb 2007 23:37:27 GMT

Wish there are more (and easier) options to export (in multiple formats)!

http://geekswithblogs.net/rachit/archive/2007/02/11/106055.aspx

Something like export directly to Visio if you have installed...so and so forth...

re: Do you use Database Diagrams?

Brian Lawton — Thu, 22 Feb 2007 00:37:57 GMT

Currently, I only use the existing diagramming functionality as a last resort to reverse engineer an undocumented model and I have no other tools available. I use diagrams all the time for documentation/reference, visual validation, and talking points with clients. However I generally create my own with ERStudio so I can reuse and build upon the metadata offline.

Andy Mackie and Marcus vR cover pretty much all I had to add regarding desired functionality. Thanks guys!

That said, my ideal database development / administrative environment (and I realize this is only a dream) would combine the modeling capabilities of ERStudio (my preferred modeling tool) with the development features of VS and administrative capabilities of Management Studio. Then I’d only need one tool instead of the three I currently use. If forced to pick between VS or Management Studio as the home for this functionality, I’d have to choose Management Studio because administrators often need to produce diagrams and do not want to install a separate tool simply to get that functionality. While as a developer I would most likely have both tools available anyway.

re: Do you use Database Diagrams?

Gabriel Schenker — Thu, 22 Feb 2007 08:28:20 GMT

As the class designer in VS2005 is just another picture of the code and thus is fully synchronized I wish the same for a future ERD tool in Data Dude. Scripts and diagrams have to always be in sync! That's the main reason why I don't use other tools like Visio or Erwin. A visual representation of your database is very important to e.g. find/discuss and improve/correct flaws in the data model. A designer is also "nicer" to define new tables and relations as typing scripts. A dual representation of the database (script and diagram) helps me very much in my daily work.

re: Do you use Database Diagrams?

Steve Hughes — Fri, 23 Feb 2007 02:47:28 GMT

I currently use ER\Studio, but I mainly use it for documentation and logical design. I do not maintain the database with it, nor do I intend to. However, I do need some way to illustrate the current schema and changes to portions of the schema that can be easily understood by the development team. So a similar tool included in DB Pro would allow me to create the design visually and deploy if desired as well as reverse engineer as needed to produce enhancement requirements documentation.

re: Do you use Database Diagrams?

Don Peterson — Sat, 24 Feb 2007 01:31:29 GMT

I use them all the time as my main tool to create and maintain my database schemas throughout the development process. I've found the diagram tools in VS 2005 to be a giant step back in that they are just really annoying to work with. My biggest complaint is with moving relationships so the are displayed an orderly manner. Everytime I try move one it creates a new joint.

I'm almost to the point that I'll continue to develop with sql 2000 until time comes to move to a production environment. Please improve these tools as soon as possible as it's costing me valuable time.

re: Do you use Database Diagrams?

Russ M. — Sat, 24 Feb 2007 06:30:00 GMT

As Gabriel Schenker said, synchronization of model and scripts in Data Dude is a must-have. Reverse-engineering, support for custom properties and full round-tripping are also needed to be a complete tool. Being able to divide and organize large data models by subject area is also important. Another thing that might be interesting would be the ability to annotate data flows on models to show the flow of data in an ETL process, for example.

re: Do you use Database Diagrams?

David Scotland — Sun, 25 Feb 2007 16:44:23 GMT

I currently wouldn't use the datbase diagramming features in VS 2005 as they are no where near up to the job.

What is required is a tool which offers the fuctionality of ER/Studio i.e. to maintain both logical and multiple physiacl models of the database so that you can accurately view the DB schema as it is in production, developemnt or staging areas. Although if you are using version control you should be able to just get the appropriatley tagged or branched verison out o the repository. But it nice to be able to compare them.

As Russ and Gabriel have said the Diagram must be kept in sync which the scripts in data dude and being able to create sub views of the model so that you can view models by subject area is required.

I cuurently use E/R studio but would love a tool which provide full round tripping do that I can work in just one tool and not have to keep reverse engineering changes into E/R studio.

re: Do you use Database Diagrams?

Neil — Sun, 25 Feb 2007 20:14:40 GMT

I currently use diagrams in both Management Studio and Enterprise Manager. My employer is too cheap to buy modeling software and we only have Visio from Office 2003 which can reverse engineer but not forward engineer. So I have been using diagrams for years to design the table structure. I also make diagrams on existing databases I inherited to help me understand the structure and how the tables are related.

My wish list for diagrams:

1. Ability to click and drag the columns into a different order.

2. For existing databases, it would be cool if it was able to make the diagram and arrange all of the tables automatically with the fewest relation lines crossing over.

3. symbols available for one-to-many, many-to-many, etc. that you could place on the end of your relation lines to show the relationship.

4. An option to toggle between full screen view and back. After all you need every pixel of screen real estate you can get when these things get big.

5. Increased context menu choices. Basically I would like the diagram to be my "dashboard" to a database, and the right click context menu pop up should have every available option that exists in the table list.

6. Option to list stored procedures that SELECT, INSERT, UPDATE, OR DELETE on a given table, in those four groups underneath the table, sort of like the VS2005 dataset designer where you have fields and methods listed underneath.

7. integrated refactoring - If I rename a table/column in the designer, I should have the option to change all stored proc's, UDF's, and views that reference that column. This really goes beyond the diagram though I realize but it would be cool and it goes with my diagram-as-dashboard-to-the-database idea.

re: Do you use Database Diagrams?

Ray Herring — Mon, 26 Feb 2007 18:00:17 GMT

Andy Mackie got in the main points. I find Visio EA to be "Too" smart (and too slow) for most of my purposes.

Two particular issues have kept me from using diagrams much. I never liked that changes in the diagram were a 'click away' from being in the database and the print/display features have been atrocious.

I have never liked having the diagrams directly affect the database. I really want a basic modeling tool (tables, relations, keys) that produces a version controlable script I can apply later. I would like to use it for both forward and reverse engineering.

Also, it is a real nuisance that the diagrams are associated with a specific db instance. I would prefer them to have a standalone existance.

Some mentioned Power Designer which I used in a previous life. I liked it very much and I think a "lite" version of it would be very useful.

re: Do you use Database Diagrams?

Nullable — Wed, 28 Feb 2007 07:51:23 GMT

I would like to implement strong declarative referential integrity in my personal one-to-one relationships. I spend a lot of idle time modeling and diagramming, but on attempting exection, all I get are a bunch of run-time errors, culminating in a giant BSOD.

re: Do you use Database Diagrams?

Simon Harvey — Wed, 28 Feb 2007 13:52:00 GMT

I use SQL Server Management Studio to simply create relationships between my tables.

I don't use it to define columns and data types (at least not often)

I'd like the ability to -

a. print the buggers easily

b. Export as a variety of image types

c. do all the things Neil said :-)

Thanks

re: Do you use Database Diagrams?

Greg Low — Thu, 01 Mar 2007 02:14:33 GMT

Hi Mairead,

I don't use the diagramming tool in a design fashion. I only currently use it as a documentation tool or, as others have noted, as a reverse engineering tool. I find the current tool more frustrating than the previous one unfortunately. It might just be the types of diagrams I'm hoping to produce but often I just want a simple diagram of the tables (but with data types and null/not null shown) along with relationships. I also constantly battle with getting it to print in a way that I'd like. A print preview would be a major help with this.

Regards,

Greg

re: How to migrate database diagrams

csabroso — Thu, 01 Mar 2007 15:27:45 GMT

Please provide any information on migrating database diagrams from SQL 2000 to SQL 2005.

Thanks.

re: Do you use Database Diagrams?

Prasanna — Sat, 03 Mar 2007 21:47:28 GMT

Feature Missing

1. Grouping of DB Table Objects in virtual boxes. For example a DB might hold objects for "Accounting" & "Finance" team/system/group, if diagram cna group them together in 2 2 seperate Virtual Groups, that helps explaining the new developers

2. Easy way of color coding tables automatically, which will help ADMINS to finetune tables or watch for tables that are either pooraly designed or always using extra resource...

re: Do you use Database Diagrams?

Sylvia — Wed, 07 Mar 2007 04:00:08 GMT

I use DB diagrams to communicate, describe and illustrate to users and developers the relationships and structure of a database contents.

In many cases, I create separate diagrams of a subset of a database tables to illustrate a component of a database used by one or more application of a bigger system.

I use VISIO a lot for documentation and notation the information in the database diagrams and then add the images into a word document for various application design or user/operational documents.

I have found a lot of developers needing to the a component of the the data diagram in order to understand the relationship for reporting or programming.

Having database diagrams (ala VISIO) would within Visual Studio for all levels is get to keep the application self-documenting.

I recently discovered a data dictionary report with VISIO 2003 which would be great to include into VS. for those organization that require (as most do) a data dictionary of the database tables and fields that are logical to some and uncomprehensible to others.

-- Sylvia

re: Do you use Database Diagrams?

Matthew Martin — Wed, 07 Mar 2007 06:23:23 GMT

1) I'm solving the problem of what tables, what columns and what links they should have. If I choose wrong

2) Recently I used E.M. to fulfill a documentation requirement. When I have serious work I switch to FabForce, which targets MySQL but is close enough to T-SQL, for some reason, diagramming with is pretty quick. And the charts are printable, unlike E.M. which requires a screen-shot-paste-into-paint process.

3) ROUND TRIP. Let me turn an existing db into a set of charts and turn a set of charts for me into a set of tables. The change things as you go model used in EM seemed to encourage unrepeatable changes.

4) I use EM, SSMS seems to have the same bits as EM for db diagraming. While I use VS2005 everyday for writing code, I woudn't know if there was db diagraming tool in there. Visio is a joke: try taking a typical business database with 50-100 columns per table.. the table icons are taller than the paper.

re: Do you use Database Diagrams?

Chuck Lathrope — Wed, 07 Mar 2007 20:57:31 GMT

It would be nice for it to keep snapshots in time so I can store versions and for it to keep record of what has changed since diagram was last looked at.

Then add easy capability (drag and drop or push an icon) of new objects into diagram if I want. Also want ability to exclude objects easily with regex search capability. I have one database with 700 tables and 1500 stored procedures. My exclusions need to be persistant and modifable. I don't want to have to manually search through thousands of objects.

re: Do you use Database Diagrams?

Simon Jones — Sun, 11 Mar 2007 13:32:43 GMT

We use SQL Server's diagrams to quickly see how tables relate to each other in databases that are new to us. We also use Visio for more permanent diagrams, with colour, notes, etc but Visio is very bad at letting lines cross and Visio diagrams need a lot of tidying up to be presentable. SQL Server diagrams are "instant" but limited.

re: Do you use Database Diagrams?

ElBruno — Sun, 11 Mar 2007 19:32:29 GMT

Of course we use diagrams !!!

I personally think they are the best way to have a quick view of a database ... :D

re: Do you use Database Diagrams?

Merrill — Wed, 14 Mar 2007 01:59:50 GMT

Yes! I use them mainly for design of small-to-midsize databases. For very large/complex DBs they do tend to become hard to manage and slow.

re: Do you use Database Diagrams?

Gerard van de Ven — Tue, 20 Mar 2007 02:54:03 GMT

I use database diagrams quite a lot, but only in SQL Server. They give me a quick and easy overview of (part of) the data model. I can use this to easier look up relations and create queries. In one diagram I can see exactly what tables to join, what all the column types are and the lengths of the text columns I put in.

This is all so much more efficient than having to check the textual table definitions all the time.

My databases normally vary from 5 to 30 tables. This is easily managed by SQL Server using different diagrams, combining related diagrams.

I always show foreign key relations and it would be helpful if I could switch off some of them manually in the diagram. For example when I keep "created", "last modified" data for records in the tables, all the tables have foreign key relations to the User table. This can clutter up a diagram quite a lot. I would love to switch off these relationships and only show the import ones.

re: Do you use Database Diagrams?

Mark Challen — Tue, 20 Mar 2007 14:51:56 GMT

I have relied in ErWin for years, it's best feature was Complete Compare (synchronization).

The diagramming in SQL2005 (VS2005 has it? Who knew?) is handy for small-scale design tasks but quickly becomes unwieldy. It's fine as a "free" diagramming tool, I'd like to see column rearrangement by drag-drop and the ability to export the diagram.

If MS added full round-trip modelling in DbPro 2.0 I'd be a happy camper.

re: Do you use Database Diagrams?

Craig Dunn — Tue, 27 Mar 2007 06:37:31 GMT

We use database diagrams a lot; although it's a very simple tool it's the easiest one to use. In particular we draw and store documentation as diagrams, and because our methodology builds the database from source-control every time, we also script them to files.

http://www.codeproject.com/dotnet/ScriptDiagram2005.asp

There is also a solution to script diagrams in 2000, but I've tried 'moving' the binary data from 2000 to 2005 without luck; would love some inside info on how the binary format changed so that a conversion 'script' would be possible.

A future, more powerful tool would *have* to be able to script the diagrams out for source-control purposes and rebuilding/deployment. Perhaps an Xml-based-format is in the tool's future? Refactoring via such a UI would also be great.

Update on Visual Studio Team Edition for Database Professionals

Jeff Lynch [MVP] — Tue, 10 Apr 2007 16:45:34 GMT

My team has been using VS DBPro (DataDude) for a little over six months now and I thought I give you an update on how we use this tool in a "mixed" environment (SQL Management Studio & DataDude), what we like and what we'd like to see in future releases

re: Do you use Database Diagrams?

Ericga — Sun, 15 Apr 2007 17:47:41 GMT

I am using SSMS because VS is slow as a turtle on valium. I use VS for C# development only. (should also point out that SSMS is always installed even on a production server but it is sometimes totally impossible to install VS or connect to a db with VS because of security policies).

Other reason to use it: the visual is stored WITH the database. It is also orders of magnitude faster that Visio. I prefer to do without than use Visio.

- some windows can't be resized and some are way too small. Check constraints comes to mind (that one is really stupid). A composite window for editing would be better than all those small dialogs.

- would love it if it stopped adding parenthesis each time a check constraint is saved. When comparing schemas we end up with differences like ((((<check)))) versus (<check>) simply because one has been modified a few times with the designer.

- current support for schemas and collations is awful

- designing FK is a royal pain when you link to unique constraints instead of PK.

- supporting views of course. Also supporting "implicit" FK with views. Obviously SQL2k5 does not support FK to views or between tables of different dayabases, but explaing relationships between views and tables is still important. Those relations are a different beast (part of the diagram but not the schema) and should display differently (dotted for example). Also useful to show relations to external entities (other db, other server, etc.)

- the "re-arrange" algorithm is mostly a mess. Lose way to much time trying to manually dispose tables correctly. Improving (well, replacing) the algorithm (hierarchical layout would be better) and/or supporting more than one. Being able to pin tables in the layout so we don't lose manual work.

- support for colors would be good. Color laser printers are now common.

- being able to export the visual to PDF, PNG and WMF would be good. XAML should be seriously considered.

- much better support for user-defined extended properties would also be good (LARGE text box please. It stores up to 7k).

- being able to save a change script instead (or on top) of executing it is necessary.

- it is painfully slow to work with large (1000+ tables) databases. Using profiler it is obvious that way too many queries are issued (row by row processing is used many places)

- it does not support multiple monitors correctly. You never know were a window will pop and SSMS can even open on a monitor that is not there anymore.

- If there was a way to optimise a diagram based on the page size used for printing, it would save loads of time.

- being able to easily filter the list of tables using the LIKE syntax would help (RegEx is great but most dbas are not familiar with it and everybody is familiar with the LIKE syntax)

- if there was a way to save the diagram in xaml and have a special reader that could display, zoom, navigate dependencies, search, etc. it would be a killer. Being able to distribute the schema to developers so they can consult it easily (see the relations and the extended properties annotations) in a WPF environment would be great. (I can dream, can't I:-). Not sure if navigating your schema in 3D would be useful, but it sure would be fun lol. That would be a very popular WPF showcase among developers to say the least.

re: Do you use Database Diagrams?

Ian_E — Sun, 22 Apr 2007 02:34:33 GMT

I use the diagrams mainly for setting up primary key / foreign key relationships between tables.

I really like doing it this way - it's very easy when you have such a visual tool.

I also discovered that, when setting up your relationship, you can specify an optional "Delete Rule" for what happens in a child table when the corresponding entry in a parent table is deleted. I implemented cascading deletes in this way without having to create a database trigger. I am confused however about why the "Delete Rule" is found in the "INSERT And UPDATE Specifications" category.

My only issue with the diagram tool is that you cannot go back & edit a relationship after you've created it (at least I haven't figured out how); consequently I just delete the existing relationship and then create a new one.

re: Do you use Database Diagrams?

Goober — Sat, 05 May 2007 05:20:07 GMT

I'm mainly using diagrams to print out entities and relationships for quick reference. We have several enterprise databases with 1,000+ tables. A 3 foot x 12 foot banner with the entities logically grouped is a priceless time saver we use daily.

So, two thumbs up to ericga who said:

- If there was a way to optimise a diagram based on the page size used for printing, it would save loads of time.

I just spent 4 days making a diagram manually...

I need a layout dialog that lets me pick a page, a logical group of tables/views, and fits them on the chosen page(s).

This would require being able to create logical groups in the first place.

It would be very nice if when 2 relationship lines crossed one of the lines had a little hump over the other line. This would make it possible to actually follow a line.

View options:

1. Line width for relationships.

2. Line color for cardinality.

3. PK icon. Hide it, show PK's and FK's columns as text in brackets following the column name. This will save a ton of horizontal space because all the column names won't have to be shifted the 18 or so pixels they are now.

4. Autosize: truncate options for entity names, column names, etc.

5. Allow relationship lines to run under tables? choices are NO, NO, and NO.

Ditch the vertical scroll bars on the entities. They suck. The 2005 solution of dealing with the sucky issus where they've decided to just autosize to a row and a half of extra vertical white space was not a good idea. They also take too much horizontal room and cause everything to get displaced and shifted when you change zoom level and they magically appear. What good are they when printed? Yikes!!

Perhaps a 1/2 line "more" button, (like some office menus), at the end of the table/view would suffice? Printed you'd see some columns were hidden and when interacting you could hover the mouse to temp expand it, or click to permanent expand.

There's more, but this post is long enough. Simply take a large database and try to print the entities on a roll-fed plotter or ink-jet. You get the idea.

--Goob

P.S. I need my diagrams to be save-able in TFS source control, and NOT hooked to any specific database instance except when I tell it to do so. And not to automatically update itself when it is connected. Give me a dialog that lets me choose what changed entities to update on my diagram and when to make the update.

P.P.S. Thanks for asking. I needed the vent :-))

re: Do you use Database Diagrams?

Goober — Sat, 05 May 2007 05:39:24 GMT

One more thing:

Show the dang margins when showing page breaks. And don't put anything there when arranging tables.

As it is now, I have to guess if I've encroached on a margin, and if I have, I get 2 each 12 foot long pages! One of them has 10 pixels of a table on it. grrrrr. (Probably my printer driver trying to do the right thing.)

O.K. One more, more thing, then I'm going home. Otherwise I'll be here complaining all nite:

Give me the option not to print page numbers. PRETTY PLEASE.

My plotter is smart enough to cut the paper at the end of the inked area. The problem is that plotters see the page as 36" wide (the roll width) and 12 feet long (my custom paper size, which then has to be set to landscape to get banner). If I create a diagram where I don't need more than 3 feet horizontally I print in portrait mode, where I may only need 1 or 2 feet vertically. The problem is the diagram tool then adds a page number 12 feet down, and of course the plotter sees this and wastes 10 feet or so of paper so it can write a useless page number.

OUCH.

--Goob

re: Do you use Database Diagrams?

Doug Ramirez — Mon, 26 Nov 2007 05:30:44 GMT

I don't use database diagrams because the tools for using them *ALWAYS* exist out of the context that they are needed in. That being the context that models the database that will store the state of your objects in your class model.

As LINQ evolves and bridges the gap from code to database persistence languages, it should make the emphasis on modeling your app first, database later more important.

So using database diagrams really should be renamed application data persistence diagrams that show the 'things in the application' and how they persist data in the 'things in the database.'

An E/R diagram tells you nothing about how the database is used. Yes, tables have columns that are typed, and they have keys and indexes, etc. That picture is void of use and behaviors and rules.

Once the modeling can encompass the classes that use the db schema objects and a diagram of those entities and their interaction are described visually, suddenly that diagram has value and can facilitate substantive conversations amongst the development team.

This is what we need.

re: Do you use Database Diagrams?

Adam Harris — Mon, 21 Jan 2008 18:54:15 GMT

It is the $6m question.

- I suggest strongly to have crow foot instead of the bad key and infinity sign, and to make the relationship single line instead of 3D pipe, with the option to have dotted line at the one, many or both ends, and the option to control the boldness of the line.

- I like to be able to reduce the table width to the minimum.

- I like to add more options on the relationship context menu, such as rename and properties.

- The current relationships can be only at right angle, so I like more control like Visio to make different angles and curves.

- After I edit the database at another environment I like to click refresh on the ERD.

- I like an option to have all tables auto-size in height so to fit all fields.

- we can get more space by reducing the height of each field and the left margin on the text, and reduce the width of the gray square on the left.

- Many more.

re: Do you use Database Diagrams?

scott ocamb — Sun, 09 Mar 2008 22:22:28 GMT

I typically use diagrams to model the database and communicate it to the users and or developers. I use ENTERPRISE ARCHITECT to model process flows, state diagrams and also data models.

I find this much better than visio.

EA will also generate the sql for the database and allows for very good comments that help users understand.

So, i would like to se some sort of diagram tool in the database version of Visual Studio Team Edition.

re: Do you use Database Diagrams?

Karsten Breivik — Thu, 17 Apr 2008 15:55:13 GMT

Truly visionary comments by Ericga and Goober.

I completely agree on the comments from Ericga on the layout algorithm.

It would be nice to have the possibility to choose between orthogonal, hierarchical, tree, and symmertric layouts. There are ready made libraries for managing this, so it should be possible to do.

The real benefit of doing this, is to check for compliance to normal forms. A DB in 3NF should always be possible to lay out graphically 2-dimensionally without having lines crossing. Crossing lines would be a very simple indication of tranistice dependencies indicating that the database is not in 3NF.

Another nice feature would be the ability to somehow group the tables based on their use in stored procedures and views. Could be difficult to implement, but it sure would be fun to have... Say that you list our procedures on the left side of the window and use checkboxes to select procedures which should have their tables grouped in the layout...

Also I agree wih Ericga that "3 dimensional feature" and "fit layout to print" that Ericga speaks of would be a dream come true.

Brgds Karsten

Visual Studio Team Editon for DB Pro - Mairead's version : Do you use Database Diagrams?

Dating — Sun, 01 Jun 2008 11:34:06 GMT

Like my recent post on database projects, we would like to understand your current usage of the Database Diagrams feature which shipped as part of Visual Studio 2005 and SQL Server 2005. Getting feedback on your usage, helps us to get a deeper understandin

Visual Studio Team Editon for DB Pro - Mairead's version : Do you use Database Diagrams?

Weddings — Fri, 06 Jun 2008 09:02:10 GMT