使用“真实”的数据库建模工具有什么意义?

一个很好的问题。第一件事。正如您所暗示的,构建和维护一个好的数据模型不需要数据模型工具。但是,如果您将其作为工程周期的一部分,它可以加快实现时间,并在产品的整个生命周期中大幅降低维护成本。

为了证明工具的使用是合理的,它必须是开发中不可或缺的一部分。要成为一个整体,它必须是容易和直观的使用,不应损害您的整体产品。

如果您只是使用它来创建漂亮的图片,那么图表将很快变得过时,并且维护它所需的努力将不断与实际的工程任务相抗衡。

换一种说法,如果Eclipse或Visual Studio只是为了打印而美化代码,那么我们仍然会使用记事本。

正确的ER工具必须在实质上提高您的交付能力,并促进您与技术和非技术人员交流设计的能力。正确的工具会让你看起来更棒(更棒?).

除了创建一个初始模型来直观地解释您的设计之外,一个伟大的ER工具还应该执行以下操作:

• 直接从模型生成可用的模式脚本。
• 将对活动副本所做的更改合并回模型。
• 根据模型和实时数据库之间的比较创建更改脚本。
• 允许您维护数据定义并轻松发布它们。
• 将您的设计转换为任何主要的SQL风格。
• 允许您创建视觉上吸引人的子模型,自动同步到主模型。
• 允许您定义实体模板,因此不必为所有表创建相同的系统列(插入日期、插入用户、修改日期…)。
• 为您的模型提供逻辑和物理视图,这样您就可以在图表中同时使用人类可读的列名(名字)和物理列名(名字)。前者最适合非工程师,而后者为您提供了根据自己的最佳实践命名列的能力。
• 随着时间的推移,为您提供一种轻松的模型版本控制方法。

erwin、mysql workbench和er/studio都是直观易用的工具示例,使您能够专注于自己的设计,而不是如何使用该工具来完成基本任务。还有其他的。这些是我有经验的。

Erwin目前有一个免费软件版本,您可能会发现它在确定某个工具是否适合您的环境方面很有用。

Visio只提供对初始模型进行反向工程的功能。

我希望这能帮助你做出决定。

从Visual Studio 2008开始,有一个数据库版本具有SQL Server 2005项目类型。通过这个,您可以从数据库中获取模型(SSMS图中的模型)并为其生成脚本。接下来,您可以对模型的不同版本进行模式比较,并使用生成的脚本将旧版本更新为新版本。对数据也可以这样做。

有一个Oracle工具-企业元素
该工具允许您通过输入有关系统的元数据动态创建数据库, 然后为您生成所有的UI。您可以动态更改模型,自动调整报告和基于Web的表单等。 也许是重新设计的好选择,你想保持流畅

我会选择一个涉及大量创建模式的廉价尝试和大量示例事务的真实模型代码的方案。如果它不支持往返(即从模式中重写图表并编写模式以匹配图表中的更改),那么您可能会尝试不继续调整模式,因为要让它们再次匹配需要花费很长时间。

因此,EnterpriseManager(我认为ManagementStudio)中的数据库图表绘制程序将远远优于Visio。

我正在使用MySQL工作台。

http://en.wikipedia.org/wiki/MySQL_Workbench

http://wb.mysql.com/

从我发现的情况来看,专用的DB图表工具与基础的图表导向工具(如Visio)相比有许多优势:

1. 支持从现有数据库生成图表
2. 支持生成一个alter脚本以将您所做的更改应用于图表
3. 支持将关系图与现有数据库进行比较

还有许多其他的,但简而言之,专用工具将具有更多的集成特性,可以利用现有数据库的模式,这使得管理它们更加容易,特别是在过渡场景中。

老实说,我认为现在产生DDL在很大程度上是一种卫生功能。如果您的项目是一个“繁重的”数据库项目,并且您有一个DBA和所有这些好东西,那么您几乎肯定会开发一个数据库的项目方法;该方法很可能包括逻辑和物理设计、验证、样本数据、需求的可追溯性以及所有这些木制品。在这种情况下,获得一个适当的工具-尽管要知道他们中的许多人有一个相当陡峭的学习曲线,并希望你以他们独特的方式看待世界。例如,我从来没有设法掌握欧文的窍门,但我发现明星设计师更符合我的口味……

如果您的数据库只是业务层存储其数据的地方,而数据库不是项目的关键驱动因素(Web应用程序通常是这样),那么我不会太过强调它——通过查看连续的数据库集成和其他允许数据库在开发中发展的方法。