在使用O / R映射时,我从哪里开始设计?对象或数据库表?

时间:2008-11-08 00:28:50

标签: database-design orm

我正在启动一个新的数据库应用程序,我想知道在对象上启动设计(使用UML)并相应地构建数据库模式,或者从数据库的设计开始(使用ER)是否更好相应地创建对象。

这两种方法的优点和缺点是什么?

(我认为这不重要,但以防万一:我打算使用Java和Hibernate)

8 个答案:

答案 0 :(得分:12)

取决于您的应用程序是否旨在满足用户需求,或满足开发人员的需求。

从用户故事开始,直接获得OOP课程。而且你的用户会爱你。

否则,您最终会得到一个将用户转变为数据录入员的应用程序。 (你会有很多公司。)

答案 1 :(得分:5)

从数据库开始的优点是你会考虑到性能和DBA。

从OOP开始的优点是你将拥有更纯粹的OO设计,但你的ORM可能表现不佳。

我发现黑盒ORM限制太多,所以我的系统都是手工编码或生成和修改的代码,因此我的数据库通常很紧,我的OO模型是纯粹的。我坚信聪明的人是阻抗不匹配的解决方案。

答案 2 :(得分:4)

这取决于你的优势所在,以及你想去的地方。

你可以从对象开始,做得很好,包括你的数据库中的好桌面设计,如果你在正确的地方开始。

从面向对象的分析开始,而不是面向对象的设计。我无法强调分析和设计之间的区别。撰写关于面向对象分析的人,其中一些人使用UML作为工具,试图清楚地做出这种区分。分析属于问题域,而设计属于解决方案域。无论您的方法是否面向对象,这些都可以很容易地相互混淆。

如果您对项目的要求进行了良好的OOA分析,那么您可以合理地并行构建概念数据模型,并使这两者保持同步。当您构建概念数据模型时,我建议您保留一个类似ER模型的模型。

ER模型不会告诉您如何设计数据库。这就是重点。将分析问题与数据建模中的设计问题分开的方法是使用ER建模和使用关系数据建模的设计进行分析,至少在开始时。

OOA和ER之间的映射非常简单,您可以并行管理这两个模型。可能有更新的工具可以为您管理这两种模型。 ER和RDM之间的映射看似简单。在最简单的映射中,您将每个实体转换为一个以实体身份为基础的表,并将每个关系转换为一个单独的表,该表键入引用实体的外键。通过将一些外键插入实体表来减少表的数量是可能的,也是可取的,但这是一个细节。

从OOA开始,您可以前往OOD进行设计,使用OOP进行编程。

从概念数据建模的ER开始,您将继续使用RDM进行逻辑数据建模,并使用DBMS特定的SQL方言进行物理数据建模。如果你的项目太大而无法在纸上或白板上进行建模,肯定有工具可以帮助你解决这个问题。

您可以定期构建您所拥有的内容,也可以使用未构建部分的存根,以及您 协调您的应用程序设计与数据库设计。如果你做得好,在一天结束时,你应该处于良好的状态。

如果您一次设计一个数据库和多个应用程序,事情会变得非常有趣。

答案 3 :(得分:2)

从数据库级别开始肯定会允许您创建一个更容易由常规关系数据库处理的数据库。因此,如果您希望获得数十万甚至数百万个对象,这就是我要采取的方法。但是,如果您不希望获得那么多数据,或者性能无关紧要,我会选择对象方法,因为它可以让您为实际应用程序更加流畅地构建一个解决方案。

答案 4 :(得分:2)

这取决于您希望获得最佳性能的位置。如果您希望数据库成为您的瓶颈,那么就开始在那里设计,以便您可以根据性能进行调整。如果您只使用数据库来保存应用程序中需要高性能的几个对象的状态,那么请相应地进行设计。 O / R映射软件在性能调优方面不是那么可靠(但它们不会很快赶上),因为它是一个优秀的编译器。您仍然可以更好地设计性能(尽管前期开发成本更高)。

答案 5 :(得分:2)

如果您正在编写OO应用程序,那么我发现首先设计对象是开始的地方。我宁愿创建一个好的OO设计,然后尝试优化数据库而不是构建数据库,然后尝试将对象适合数据库。

ORM工具让您可以自由地将注意力集中在对象设计上。

但是,它并没有取代良好的数据库设计。您仍然需要密切关注数据库。我发现经过仔细考虑,可以完成OR映射,以便创建的数据库得到相当优化。如果发现某些查询表现不佳,您可以随时查看查询并尝试对其进行优化。

您不必构建符合数据库模型的应用程序,数据库应设计为支持您的应用程序。 ORM工具允许您创建优化的数据库和查询。

答案 6 :(得分:1)

这取决于。你在做面向对象的编程还是面向SQL的编程?

答案 7 :(得分:1)

任何一种方法都可行,每种方法都有其优点和缺点。以数据库为中心的方法非常适合共享数据的许多应用程序。以对象为中心的方法非常适合启动和运行单个应用程序。

如果数据库不存在,我会考虑构建应用程序而不必担心它。也许像db4objs这样的东西可以在你将应用程序发展成有用的东西时为你提供所需的对象持久性。之后,当新应用程序被设计为共享数据,或者即席查询变得重要时,关系数据库映射更有意义。也许你永远不需要关系。在需要时构建它。

如果数据库已经存在,或者需要在那里获取数据,我仍然会尽可能地推迟关系工作,并使对象和代码正常工作。但是如果我看到自己编写可以通过SQL完成的复杂代码,我就会改变主意。