A great question. First things first. As you have implied, a data model tool is not required to build and maintain a good data model. But, if you make it part of your engineering cycle, it can speed implementation time and drastically cut down on maintenance costs over the life of your product.
To justify the use of a tool, it has to be an integral part of your development. To be integral, it must be easy and intuitive to use and should not impair your overall productivty.
If you just use it to create pretty pictures, the diagrams will quickly become obsolete and the effort required to maintain it will constantly be pitted against real engineering tasks.
To put it another way, if all Eclipse or Visual Studio did was beautify our code for printing purposes, we'd still be using notepad.
The right ER tool must materially improve your ability to deliver and facilitate your ability to communicate design to technical and non-technical staff. The right tool will make you look awesome (more awesome?).
In addition to creating an initial model that you can show to visually explain your design, a great ER tool should do the following:
Generate usable schema scripts directly from your model.
Merge changes made to a live copy back into your model.
Create change scripts based on a comparison between your model and a live database.
Allow you to maintain data definitions and publish them with little effort.
Translate your design into any of the major flavors of SQL.
Allow you to create visually appealing sub-models that automatically sync to the main model.
Allow you to define entity templates, so you don't have to keep creating the same system columns (insert date, insert user, modify date...) for all tables.
Provide you with both logical and physical views of your model, so you can use both human-readable column names (First Name) as well as physical column names (first_nm) in your diagrams. The former is best for non-engineers while the latter provides you with the ability to name columns based on your own best practices.
Provide you with a painless way of versioning your model over time.
ERWin, MySQL Workbench and ER/Studio are examples of tools that are intuitive to use, allowing you to focus on your design and not on how to use the tool to do basic tasks. There are others. These are the ones I have experience with.
ERWin currently has a freeware version that you might find useful in determining whether a tool will work for your environment.
Visio only provides you with the ability to reverse-engineer for the initial model.
从 Visual Studio 2008 开始，有一个数据库版本具有 SQL Server 2005 项目类型。这样，您可以从数据库中获取模型（SSMS 图中的模型）并为其生成脚本。接下来，您可以对模型的不同版本进行架构比较，并使用生成的脚本将旧版本更新为新版本。数据也可以这样做。
As of Visual Studio 2008, there is a database edition which has a SQL Server 2005 project type. With this you can take a model from a database (model in SSMS diagram) and generate script for it. Next you can do schema compares to different versions of your model and use the resulting scripts to update older versions to newer versions. The same can be done with data.
that tool allows you to create the database dynmaically by entering the metadata about the system, and all UI is then generated for you. you can change the model on the fly, which automatically adjusts the reporting and web based forms etc. maybe a good choice for a redesign that you want to remain fluid
I would choose the one that involves lot of inexpensive attempts to create a schema and lots of real mockup code of sample transactions. If it doesn't support round tripping (ie. rewriting the diagram from the schema and writing the schema to match changes in the diagram) you will be tempted to not keep tweaking the schema because it would take forever to get them to match each other again.
So the database diagrammer in Enterprise Manager (and I think Management Studio) would be far superior to Visio.
From what I have found out, there are a number of advantages a dedicated DB diagraming tool has over a basic diagram-oriented tool like Visio:
Support to generate a diagram from an existing database
Support to generate an alter script to apply the changes you made to a diagram
Support to compare a diagram against an existing database
There are many others, but in a nutshell, the dedicated tools will have many more integration features that leverage the schema of existing databases, which make managing them MUCH easier, especially in a transition scenario.
To be honest, I think that generating the DDL is pretty much a hygiene function these days. If your project is a "heavy lifting" database project, and you have a DBA and all those good things, you will almost certainly develop a project approach to the database; that approach may well include logical and physical design, validation, sample data, traceability to requirements and all that good stuff. In that case, get a proper tool - though be aware that many of them have a fairly steep learning curve, and want you to see the world in their idiosyncratic way. I never did manage to get the hang of ErWin, for instance, but found StarDesigner to be much more to my tastes...
If your database is just where your business layer stores its data, and the database is not the key driver for the project (which is usually the case with web apps), I wouldn't stress about it too much - you'll get a far bigger bang for buck with looking at continuous database integration and other ways of allowing a database to evolve under development.
发布评论
评论（6）
这是一个很好的问题。首先要事。正如您所暗示的，构建和维护良好的数据模型不需要数据模型工具。但是，如果您将其纳入工程周期，则可以加快实施时间并大幅降低产品生命周期内的维护成本。
为了证明工具的使用是合理的，它必须是您的开发中不可或缺的一部分。为了成为一体，它必须易于使用且直观，并且不应该损害您的整体生产力。
如果您只是用它来创建漂亮的图片，那么图表很快就会过时，并且维护它所需的努力将不断与实际的工程任务相冲突。
换句话说，如果 Eclipse 或 Visual Studio 所做的只是为了打印目的而美化我们的代码，我们仍然会使用记事本。
正确的 ER 工具必须能够显着提高您交付设计的能力，并促进您向技术和非技术人员传达设计的能力。正确的工具会让你看起来很棒（更棒？）。
除了创建可以展示以直观地解释您的设计的初始模型之外，出色的 ER 工具还应该执行以下操作：
ERWin、MySQL Workbench 和 ER/Studio 是使用直观的工具示例，使您能够专注于设计，而不是如何使用该工具来完成基本任务。还有其他的。这些是我有经验的。
ERWin 目前有一个免费软件版本，您可能会发现该版本对于确定工具是否适合您的环境很有用。
Visio 仅为您提供对初始模型进行逆向工程的能力。
我希望这对您的决定有所帮助。
A great question. First things first. As you have implied, a data model tool is not required to build and maintain a good data model. But, if you make it part of your engineering cycle, it can speed implementation time and drastically cut down on maintenance costs over the life of your product.
To justify the use of a tool, it has to be an integral part of your development. To be integral, it must be easy and intuitive to use and should not impair your overall productivty.
If you just use it to create pretty pictures, the diagrams will quickly become obsolete and the effort required to maintain it will constantly be pitted against real engineering tasks.
To put it another way, if all Eclipse or Visual Studio did was beautify our code for printing purposes, we'd still be using notepad.
The right ER tool must materially improve your ability to deliver and facilitate your ability to communicate design to technical and non-technical staff. The right tool will make you look awesome (more awesome?).
In addition to creating an initial model that you can show to visually explain your design, a great ER tool should do the following:
ERWin, MySQL Workbench and ER/Studio are examples of tools that are intuitive to use, allowing you to focus on your design and not on how to use the tool to do basic tasks. There are others. These are the ones I have experience with.
ERWin currently has a freeware version that you might find useful in determining whether a tool will work for your environment.
Visio only provides you with the ability to reverse-engineer for the initial model.
I hope this helps you in your decision.
从 Visual Studio 2008 开始，有一个数据库版本具有 SQL Server 2005 项目类型。这样，您可以从数据库中获取模型（SSMS 图中的模型）并为其生成脚本。接下来，您可以对模型的不同版本进行架构比较，并使用生成的脚本将旧版本更新为新版本。数据也可以这样做。
As of Visual Studio 2008, there is a database edition which has a SQL Server 2005 project type. With this you can take a model from a database (model in SSMS diagram) and generate script for it. Next you can do schema compares to different versions of your model and use the resulting scripts to update older versions to newer versions. The same can be done with data.
有一个 Oracle 工具 - Enterprise Elements
该工具允许您通过输入有关系统的元数据来动态创建数据库，
然后所有的 UI 都会为您生成。您可以动态更改模型，从而自动调整报告和基于网络的表单等。
对于想要保持流畅的重新设计来说，这可能是一个不错的选择
there is an Oracle tool - Enterprise Elements
that tool allows you to create the database dynmaically by entering the metadata about the system,
and all UI is then generated for you. you can change the model on the fly, which automatically adjusts the reporting and web based forms etc.
maybe a good choice for a redesign that you want to remain fluid
我会选择一种涉及大量廉价尝试来创建模式和大量示例交易的真实模型代码的方法。如果它不支持往返（即从模式重写图表并编写模式以匹配图表中的更改），您将倾向于不继续调整模式，因为要花很长时间才能使它们相互匹配再次。
因此，Enterprise Manager（我认为 Management Studio）中的数据库图表绘制器将远远优于 Visio。
I would choose the one that involves lot of inexpensive attempts to create a schema and lots of real mockup code of sample transactions. If it doesn't support round tripping (ie. rewriting the diagram from the schema and writing the schema to match changes in the diagram) you will be tempted to not keep tweaking the schema because it would take forever to get them to match each other again.
So the database diagrammer in Enterprise Manager (and I think Management Studio) would be far superior to Visio.
据我所知，与 Visio 等基本的面向图表的工具相比，专用的数据库图表工具具有许多优势：
还有很多其他工具，但简而言之，专用工具将具有更多利用现有数据库模式的集成功能，这使得管理它们变得更加容易，尤其是在过渡中设想。
From what I have found out, there are a number of advantages a dedicated DB diagraming tool has over a basic diagram-oriented tool like Visio:
There are many others, but in a nutshell, the dedicated tools will have many more integration features that leverage the schema of existing databases, which make managing them MUCH easier, especially in a transition scenario.
老实说，我认为现在生成 DDL 几乎是一种卫生功能。如果您的项目是一个“繁重”的数据库项目，并且您拥有 DBA 和所有这些好东西，那么您几乎肯定会开发一种数据库的项目方法；该方法很可能包括逻辑和物理设计、验证、样本数据、需求的可追溯性以及所有这些好东西。在这种情况下，请获得一个合适的工具 - 但请注意，他们中的许多人都有相当陡峭的学习曲线，并希望您以他们独特的方式看待世界。例如，我从未设法掌握 ErWin 的窍门，但发现 StarDesigner 更符合我的口味...
如果您的数据库只是业务层存储数据的地方，并且数据库不是业务层的关键驱动程序项目（通常是网络应用程序的情况），我不会对此强调太多 - 通过查看持续的数据库集成和允许数据库在开发中发展的其他方法，您将获得更大的回报。
To be honest, I think that generating the DDL is pretty much a hygiene function these days. If your project is a "heavy lifting" database project, and you have a DBA and all those good things, you will almost certainly develop a project approach to the database; that approach may well include logical and physical design, validation, sample data, traceability to requirements and all that good stuff. In that case, get a proper tool - though be aware that many of them have a fairly steep learning curve, and want you to see the world in their idiosyncratic way. I never did manage to get the hang of ErWin, for instance, but found StarDesigner to be much more to my tastes...
If your database is just where your business layer stores its data, and the database is not the key driver for the project (which is usually the case with web apps), I wouldn't stress about it too much - you'll get a far bigger bang for buck with looking at continuous database integration and other ways of allowing a database to evolve under development.