Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Less and Less Visual Expand / Collapse
Author
Message
Posted Thursday, June 26, 2014 7:49 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 5:09 AM
Points: 1,729, Visits: 1,141
CodeFirst has a few nice features...there's the power tools and multiple diagrams per model features:
http://www.entityframeworktutorial.net/EntityFramework5/multiple-diagrams-in-entity-framework5.aspx
Post #1586437
Posted Thursday, June 26, 2014 8:03 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, September 25, 2014 12:29 PM
Points: 3, Visits: 3
Well Gary I have to agree with you there. However it is at that point where applications that can turn a diagram into usable code come in handy. Granted generated code is not always the best code, it provides a framework for the work at hand. I have found it useful to be able to go back and forth between a graphical representation for the conceptual view and go to the code (text) to make the fine tuning. Without the ability to 'See' the objects in context I find myself slipping back into procedural (spaghetti) code rather than object-oriented code. I guess that shows my age and that I started out as a programmer but not of databases where I find myself now.
Post #1586451
Posted Thursday, June 26, 2014 8:36 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Today @ 11:42 AM
Points: 755, Visits: 1,927
Gary Varga (6/26/2014)
[quote]

I agree with most of what Charles says here but, at least for my part, executable text is verifiable whereas a non-executable graphical representation is not. A document was certainly not what I had in mind.


I am ultimately more comfortable with text as the final product (though tools like Query Editor are great ways to check your work or analyze queries). Somehow I have never been completely comfortable with the graphic SSIS envirionment compared to text based techniques like SQL or Powershell.


...

-- FORTRAN manual for Xerox Computers --
Post #1586478
Posted Thursday, June 26, 2014 9:17 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 9:06 AM
Points: 371, Visits: 393
A couple thoughts came to me as I read the editorial:
1. In at least one case, when designing views, I think creating using tsql is so much easier than using that clunky table builder. My eyes spazz out when I accidentally hit the Design option on a view and see all that info stacked up on the screen. I quickly X it out and script as modify to a new query window, where I can easily read the definition of the view.
2. I've only been a DBA for 2 years, so not very experienced yet, but I have no experience using diagrams in a database. I've learned relations by exploring databases and troubleshooting issues, but I've never used diagrams. Maybe they would be easier to use, maybe not, but I haven't felt disadvantaged because the companies I've worked for don't use them.
Post #1586514
Posted Thursday, June 26, 2014 10:02 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 2:19 PM
Points: 3, Visits: 16
Back in the mid 90's, I was lucky enough to serve FedEx as subject matter expert and project lead for the first methodology-driven application to be delivered that was based on the recently completed information strategy plan for the Air Operations Division we spent nearly two years developing. As a small group of about 10, those of us who developed the plan had spent the first several months evaluating and selecting first a methodology, and second a documentation and application delivery environment to support it. We selected James Martin's Information Engineering methodology, and then the IEF toolset from Texas Instruments, precisely because it was entirely graphical in nature, and generated all the code required to implement the documented business rules and entity relationships directly from the diagrams. It went far beyond what we used to call 4GL Generators to fully integrated CASE, in that the resultant code included all the DDL, stored procedures, messaging, and client code targeted to practically any database, O/S, or browser (back when everyone used Netscape :)). So, to the point of the discussion, we have definitely digressed from what was state-of-the-art with graphical design and development tools used to be, to today.

One of the most valuable components of the IEF toolset was its powerful ERD tool. The purpose of the tool was not just for the programmers. Programmers tend to be self-interested when it comes to tools. Before anyone gets defensive, let me say I have been a programmer since the 70's, and have worked with, hired, and managed hundreds of them over the years, so I get to have an opinion. The greatest value in the ERD (and DFD, for that matter) is as a tool to gain consensus with the user about what an application is to do. The number one reason I've seen application development efforts fail is because the folks doing the programming just thought they understood what the customer wanted, and then included a healthy dose of what they "really need", and so delivered a glove that did not fit the hand as expected. Through experience, I assert that ERD and DFD are the most effective tools available, even yet today, with which to communicate analysis and design constraints back to a customer, before any coding or design is started. If you do not have an agreement on terminology, the entities involved and their relationships, and what business rules are about to be implemented, you are really wasting your time and the customer's to go any farther. ERD and DFD pictures are easy enough for any business unit manager to understand. I have taught them untold times in my career, sometimes to audiences over a hundred. I always start my presentations with a quick review of how to read the diagram, which takes 5 minutes.

The beauty of the IEF was the ability to drive the documentation to such a detailed level that the code came from it instead of vice-versa. Another common failure of applications is lack of documentation and eventual death through the inability to maintain and extend them as a result. With the IE methodology, the documentation is done first. What a concept. You actually get to know what the finished product looks like before starting. I suspect most programmers who would think that diagrams get in the way and have no value, would also allow a home builder to just start nailing lumber together to build their house without any plans or diagrams. Just trust me :)

The ugly news is, IEF is no longer available. I understand it has evolved into a product call GEN from Computer Associates, but I have no idea what it costs or what it offers. The worse news is, at FedEx we spent several million dollars over the course of three years learning the methodology and the toolset, developing the underlying information repository, ERD, AHD, RAW Matrices, etc. required to get to the generation level, and then applying them to the first application. The application was great success, and the architecture was then in place to quickly develop additional applications, but the front-end cost was high.

Today, I use the same flaccid diagramming tools that are already mentioned in this blog, like Visio, to develop my ERD and DFD for new work. I have a tool that was given to me by Texas Instruments when the IEF training was completed, called Business Design Facility, that I use if I'm the only one who will be working on the diagrams because I can't share it. I would personally love to find another tool like IEF that I could afford to own.

As a last word to programmers who dislike diagrams and favor the "makes me look really smart" approach of screens of code, please reconsider. The diagrams and CASE are not attempts to make you redundant, any more than the machine gun made foot soldiers redundant. They are just extremely effective ways to improve your efficiency and effectiveness by providing an iron clad way to understand the problem before developing the solution and removing ambiguity about whether the solution is correct or complete.
Post #1586548
Posted Thursday, June 26, 2014 10:36 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, September 15, 2014 12:58 PM
Points: 2, Visits: 32
The most cost-effective database diagramming tool I've been able to find on the market is DeZign. It is moderately priced, reliably reverse engineers databases for a number of engines, generates DDL, and offers a good level of control over diagramming options. I use this at work for ERDs: both for generating figures for design documents and for printing ANSI-D size posters. I find it much easier to use than Visio.

[url=http://www.datanamic.com/dezign/][/url]
Post #1586563
Posted Thursday, June 26, 2014 11:16 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
In my opinion many ERD tools today cater to the intensive (concerned about physical and logical modeling) crowd, and therefore unless you have a large organization who has the specialists, you do not see the diagrams. I have pushed ERDs at all the places I have consulted. However, I am not the intensive type, so stick to physical). A relatively inexpensive tool I have found and like is "ModelRight".

<><
Livin' down on the cube farm. Left, left, then a right.
Post #1586580
Posted Thursday, June 26, 2014 11:26 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, September 25, 2014 12:29 PM
Points: 3, Visits: 3
A tool I have used successfully is Enterprise Architect from Sparz Systems. it has end to end functionality in several domains, is reasonably priced, and integrates with both VS and Eclipse.
http://www.sparxsystems.com/products/ea/
Post #1586588
Posted Thursday, June 26, 2014 11:28 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, August 21, 2014 2:11 PM
Points: 914, Visits: 152
I am using ErWin to design, forward engineer the database code and produce DB documents using the Crystal Reports edition embedded in ErWin.
Hardly ever do I need to customize the ERwin-generated code once I have set up the proper options for each model (such as macros for generating constraint and index names).
Huge time-saver when making changes and keeping documentation consistent and up to date.
Diagrams are a great training aid and very helpful for evaluating enhancements.
However I typically get blank stares when I discuss the value of an ERD tool for DB projects, even with experienced developers.
I wish I knew why, my best guess is the learning curve. I admit it took me quite a while to reach the current level of productivity.



Brian
Post #1586589
Posted Thursday, June 26, 2014 1:37 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
BrianAltmann (6/26/2014)
I am using ErWin to design
...
However I typically get blank stares when I discuss the value of an ERD tool for DB projects, even with experienced developers.
I wish I knew why, my best guess is the learning curve. I admit it took me quite a while to reach the current level of productivity.



I like Erwin too.

Part of me wonders if the blank stares are because many "developers" are not trained as developers, but come too it from other domains and basically learn as they go. That has been my experience in my last several jobs. These "developers" have a very narrow knowledge band without the "classical" training.


<><
Livin' down on the cube farm. Left, left, then a right.
Post #1586640
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse