我目前正在研究用于高度可维护系统的应用程序设计的最佳实践（在相当高的水平上），从而将更改的摩擦降至最低。“数据层”是指数据库设计、对象关系映射器 (ORM) 和通用数据访问技术。
根据您的经验，在数据层开发方面，您发现了哪些常见错误和不良做法，以及您采取/实施了哪些措施/或可以建议使数据层成为开发人员更好的地方看法？
一个示例答案可能包括：导致数据层缓慢、可扩展性和可扩展性差的最常见原因是什么？+ 可以采取哪些措施（无论是设计还是重构）来解决这个问题？
我在这里寻找战争故事和一些现实世界的建议，我可以将它们构建到公开可用的指导文件和样本中。
对象关系映射是不好的做法。我的意思是，它倾向于产生只能松散地描述为“关系”的数据模式，因此它们的扩展性很差，数据完整性也很差。
这是因为适当的关系模式已经通过规范化过程，而 OR Mapping 的结果通常是实现为数据库表的对象类。这些通常不会被规范化，而是为 OO 开发人员的直接方便而设计的。
当然，在持久数据需求最小的情况下，这并不重要。
然而，我曾经在一家航运公司工作，该公司通过接管其他几家公司而发展壮大，并将集成操作系统的开发（以取代其继承的各种公司特定系统）外包给一家使用 OO 方法的公司，由 OR 映射生成的数据模式。正在开发的系统的性能特征如此糟糕，数据模式如此复杂，以至于航运公司在开发了大约两年后就放弃了它——甚至在它上线之前！
这是 OR 映射的直接结果；架构中最糟糕的复杂性（以及因此而导致的性能不佳）是由仅作为 OO 设计过程的工件创建的表的存在引起的——它们反映了屏幕布局，而不是数据关系。