ORM能克服不良的数据库设计降低其对应用程序的影响吗?

我不这么认为。ORM和对象不是魔法。如果你把它们放在一个糟糕的设计之上,它仍然是一个糟糕的设计。

如果不必马上出现每一个库存更新,您可以将它们排队,并以异步方式进行“写在后面”。但这只是掩盖了一个潜在的问题。

我建议您尝试在数据层中构建一个正确的数据库设计的映像。您没有说您使用的是哪个数据库,但是如果您使用的是SQL Server,您可以尝试使用一种技术来构建规范化视图,而不是使用更新和插入触发器。编写新代码时,将目标放在规范化视图而不是旧表上。随着时间的推移,您可以将遗留代码从设计糟糕的表中迁移出来,并逐个替换它们。最终,您将拥有一个设计良好的数据库。

一个重要的注意事项是,虽然规范化是一个重要的考虑因素,但是您还应该查看系统中的实体,以确保数据库的概念模型是正确的。一般来说,在概念层面上正确的数据库也将符合前3种正常形式,但反过来是不正确的(正常形式并不保证概念的正确性)。如果你要承担这项工作,你要确保你的系统设计正确。

对于所有新的数据库访问代码,使用ORM绝对是一个好主意。这会给你很大的灵活性。因此,编写新特性的一般步骤是:

1. 在数据库中创建一个外观,该外观使用视图显示适当的数据模型,或者,如果可能,通过重新构造表来创建。
2. 重新编写正确的数据模型的ORM代码。
3. 总是寻找机会让您的数据模型摆脱当前的常规模式。

您的最终目标应该是重构数据库。您可能希望熟悉Scott Amber关于这个主题的工作。

而且设计也不错。有时项目是预先计算好的,这样报告就可以在不超时的情况下运行。当您需要在用户界面上快速查看某个股票时,您可以对其进行合计,这并不意味着其他运行汇总所有股票的报告的人可以及时完成这项工作。预先计算一些东西通常更好。有时一次计算总比每次需要时都重新计算好。

不知道你的整个数据库设计,我不能说这是一个好主意还是坏主意在你的具体情况下,我只是指出,有很多时候,这是一个好的设计。

这种设计是有原因的,在你决定它是一个糟糕的设计之前,试着找出它们。你还是会发现设计不好,我只是说,在你不明白为什么不适合你的个人喜好之前,不要以为是这样。

如果您真的想重新设计数据库(并从管理层着手),那么在您尝试做任何事情之前,请阅读有关重构数据库的内容(这方面有很多好书)。有些事情需要考虑,应用程序开发人员通常不知道。

一般来说:没有。正如其他人指出的那样:ORM只是一个工具,用来反映应用程序内部的数据库状态和设计,适合您的编程语言。

在这种情况下:可能是的。如果您构建一个富域模型,方法alterstockportfolio(stockmovement s)可以更新相关实体(即调用适当的方法)。删除相应的数据库触发器时,逐个添加方法调用。一段时间后,您将拥有一个业务逻辑在程序代码中的应用程序,您可以在该程序代码中使用单元测试来管理它。(从写这些开始)。

为了克服性能瓶颈,通常需要预先计算这样的派生值。设计不一定很差。尽管如此,控制数据库中持久化的值的逻辑应该只在一个地方,否则您将失去对它的控制,并且“在后台”发生看似随机的更改。在我看来,一个地方应该是应用程序代码。