良好的数据层开发与设计:数据层开发中常见的不良实践是什么？

Question

我目前正在研究高可维护性系统的应用程序设计的最佳实践(在相当高的水平上)，以最大限度地减少更改的摩擦。我所说的“数据层”指的是数据库设计、对象关系映射器(ORMs)和通用数据访问技术。

根据您的经验，当涉及到数据层开发时，您发现了哪些常见的错误和糟糕的实践?从开发人员的角度来看，您采取/实施/或建议了哪些措施来使数据层变得更好？

一个示例答案可能包括:导致数据层速度慢、可伸缩性差和可扩展性差的最常见原因是什么？+可以采取什么措施(无论是在设计还是重构方面)来解决这个问题？

我在这里寻找战争故事和一些现实世界的建议，我可以将其构建到公开可用的指导文档和样本中。

Answer 1

魔术。

我使用过Hibernate，它可以自动地从数据库中存储和获取对象。它还支持延迟加载，因此只有当您请求相关对象时，才会从数据库中检索它。这是以某种我不理解的神奇方式工作的。

只要它正常工作，这一切都可以正常工作，但当它崩溃时，就不可能追踪到它。我认为我们在结合Hibernate和AOP时遇到了一个问题，不知何故，当我们的代码执行时，Hibernate还没有初始化这个对象。这个问题很难调试，因为Hibernate的工作方式非常神秘。

Answer 2

对象关系映射是一种糟糕的做法。我的意思是，它倾向于产生只能粗略地描述为“关系”的数据模式，因此它们的伸缩性很差，表现出很差的数据完整性。

这是因为正确的关系模式已经经过了规范化的过程，而O-R映射的结果通常是作为数据库表实现的对象类。这些通常不会被正常化，而是为了OO开发人员的即时方便而设计的。

当然，在持久化数据需求最小的情况下，这并不重要。

但是，我曾经在一家航运公司工作，该公司通过收购其他几家公司而发展壮大，并将集成运营系统(以替换其继承的各种特定于公司的系统)的开发外包给一家使用OO方法的公司，该公司具有由O-R映射生成的数据模式。正在开发的系统的性能特征如此之差，数据模式如此复杂，以至于航运公司在大约两年的开发之后-甚至在它上线之前就放弃了它！

这是O-R映射的直接结果；模式中最糟糕的复杂性(以及由此产生的低性能)是由于只作为OO设计过程的工件而创建的表的存在-它们反映的是屏幕布局，而不是数据关系。