Slashdot Mirror
Recommended Data Modeling Tools?
dnxthx asks: "After performing a fairly comprehensive web search (including Slashdot) I came to the (possibly incorrect) conclusion that there were no high-visibility sites that comprehensively reviewed and compared data modeling tools such as ER/Studio, ERWin, DeZign for Databases, System Architect, or Visio for Enterprise Architects. Since some of these tools can be quite expensive (ERWin is about $4K US it seems), I was wondering what the Slashdot community's experiences were with data modeling tools such as these, or some that our group has overlooked."
I assume that you are working with relational databases, although you don't mention it.. (data modeling could mean a lot of things)
:)
Some DBMSs have some decent, albeit limited graphical design tools (MSSQL, Access..)
together from borland does entity relationship diagramming, and so much more. (great tool)
I believe IBM's rational rose may also do it.
Since my job includes SQL design as a subset of my duties (i'm a developer/architect, not a DBA) these two tools are significantly more valuable than ERWin.
I just wish I could get my boss to buy them.
I also find a good set of 3x5 filecards (taped up to a whiteboard or large construction paper) an excellent starting point for my models, particularly when trying to model those main logical entities that end up driving the entire design.
Agreed! Index cards are a highly underrated technology. They're durable, easily manipulated, have a great UI, and can be used collaboratively. Plus, they don't cost $4k per user.
They have the advantage over whiteboards of being at least partially on paper should someone erase the board...
The more design I do, the less sure I get that durability is a benefit for design artifacts. After many years doing design the traditional way (with lots of documents and fancy diagrams), I switched a few years ago to doing things in the style of Extreme Programming.
It's now my feeling that any developer on a project should be able to sketch out the major objects and their relationships without much need for reference. If not, that's often a sign that the design is too confusing. And if they do need to check something, they should go right to the code: diagrams and documents get out of sync, but the source is always correct.
Of course, that means your source has to shine. It's hard work, but as Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
ONE VERY IMPORTANT ISSUE: How well does X software import DDL from Y database and generate DDL for Z database. This is important. This shouldn't be an issue but sometimes it can be. If you have to import data from an Excel spreadsheet, existing database (like mSQL, MySQL), or some exotic ODBC datasource, can X software handle it. Frankly, that's something a professional magazine has to test. That's were downloading said software in trial mode (should be fully-functional) becomes really important. Test this out for yourself. Don't believe the brochure. I had a couple of issues with this. You may be able to import via ODBC, but will you have to edit/grep/replace DDL before doing so. Trivial but annoying...
ERWin also allows the user to seperate the physical model from the data model by design. I don't think DeZign allows you to do this. This may not be an issue for you.
To be honest, although I really like ERWin, I can't justify it's expense unless you work for a bank. Take that however you want it. Seriously, it's expensive and definitely overkill for the simple developer/architect. However, if you're a DBA it's very useful.
I used to use ERWin, but just recently (at a new job) I'm using DeZign. It gets the job done and it's cheap.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
This means that referential integrity in the database serves more than to make up for bad middleware, it means that this is where business rules and other items that rarely change can be maintained. [...] Another thing that people often overlook is the fact that many times a database serves more than one application.
I don't overlook that; I actively repudiate that.
One of the fundamental notions of object-oriented programming is that is an object is data plus behavior. If you have several different chunks of code manipulating the same raw data, then that's not object-oriented programming. In which case, fine, throw out that Java and Python and go back to COBOL.
Theoretical reasons aside, there's a very practical reason for making sure that exactly one chunk of code reads and writes your raw persistent data: schema migration. As needs change, so will the schema of your persistent data. Keeping one code base in sync with that is, with much discipline, possible. But I've never seen any place that can keep multiple code bases in sync with new schemas.
If you can't migrate your schema, then you have massive design interia, meaning developers spend more and more time focusing on just making things work, rather than making new features. Which leads to dissatisfied executives, which leads all sorts of sadness.
Having your middleware control what items are stored in a table is just looking for trouble IMHO.
Without the right approach to development, this is true. With it, whether or not you're using a database at all becomes a peripheral question, rather than a central one.