良好的数据层开发和设计：数据层开发中常见的不良做法有哪些？
我目前正在研究高度可维护系统的应用程序设计的最佳实践（在相当高的水平上），从而最大限度地减少更改的阻力。我所说的“数据层”是指数据库设计、对象关系映射器 (ORM) 和通用数据访问技术。
根据您的经验，您发现了哪些常见错误和建议？从开发人员的角度来看，数据层开发方面的不良做法以及您采取/采取/或可以建议哪些措施来使数据层成为更好的地方？
示例答案可能包括：数据层缓慢、可扩展性和可扩展性差的最常见原因是什么？ + 可以采取哪些措施（无论是设计还是重构）来解决这个问题？
我在这里寻找战争故事和一些现实世界的建议，我可以将它们构建到公开的指导文件和样本中。
I am currently researching the best practises (at a reasonably high level) for application design for highly maintainable systems which result in minimal friction to change. By "Data Tier" I mean database design, Object Relation Mappers (ORMs) and general data access technologies.
From your experiences, what have you found to be the common mistakes & bad practises when it comes to data tier development and what measures have you taken / put in place / or can recommend to make the data tier a better place to be from a developer perspective?
An example answer may include: What is the most common causes of a slow, poorly scalable and extendible data tiers? + What measures can be taken (be it in design or refactoring) to cure this issue?
I am looking for war stories here and some real world advice that I can build into publicly available guidance documents and samples.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
魔法。
我使用了 Hibernate，它自动从数据库存储和获取对象。它还支持延迟加载，以便仅在您请求时才从数据库中检索相关对象。这以某种我不明白的神奇方式起作用。
只要它能工作，这一切都可以正常工作，但是当它发生故障时，就不可能追踪它了。我认为当我们将 Hibernate 与 AOP 结合使用时，我们遇到了一个问题，不知何故该对象是当我们的代码执行时，Hibernate 尚未初始化。这个问题很难调试，因为 Hibernate 的工作方式非常神秘。
Magic.
I have used Hibernate, which automatically stores and fetches objects from a database. It also supports lazy loading, so that a related object is only retrieved from the database when you ask for it. This works in some magic way I don't understand.
This all works fine as long as it works, but when it breaks down it is impossible to track it down. I think we had a problem when we combined Hibernate with AOP, that somehow the object was not yet initialized by Hibernate when our code was executed. This problem was very hard to debug, because Hibernate works in such mysterious ways.
对象关系映射是不好的做法。我的意思是，它往往会产生只能宽松地描述为“关系”的数据模式，因此它们的扩展性很差并且数据完整性很差。
这是因为正确的关系模式已经经历了规范化过程，而 OR 映射的结果通常是作为数据库表实现的对象类。这些通常不会被标准化，而是为了方便 OO 开发人员而设计。
当然，在持久数据需求极小的情况下，这并不重要。
然而，我曾经在一家航运公司工作，该公司通过收购其他几家公司而发展壮大，并将集成操作系统的开发（以取代其继承的各种公司特定系统）外包给一家使用面向对象方法的公司，由 OR 映射生成的数据模式。正在开发的系统的性能特征非常差，数据模式非常复杂，以至于航运公司在开发了两年之后就放弃了它——甚至在它上线之前！
这是 OR 映射的直接结果；模式中最糟糕的复杂性（以及由此导致的性能不佳）是由于存在仅作为 OO 设计过程的工件创建的表造成的 - 它们反映了屏幕布局，而不是数据关系。
Object-Relational mapping is bad practice. By this, I mean that it tends to produce data schemas that can only loosely be described as "relational", and so they scale poorly and exhibit poor data integrity.
This is because properly relational schemas have been through the process of normalisation, whereas the results of O-R Mapping are normally object classes implemented as database tables. These will not normally have been normalised, but will instead have been designed for the immediate convenience of the OO developer.
Of course, in cases where the persistent data requirements are minimal, this is unimportant.
However, I once worked for a shipping company that had grown by taking over several other companies, and had outsourced development of an integrated operational system (to replace the various company-specific systems it had inherited) to a company using an OO methodology, with a data schema produced by O-R mapping. The performance characteristics of the system being developed were so poor, and the data schema so complex, that the shipping company dropped it after something like two years of development - before it even went live!
This was a direct consequence of the O-R mapping; the worst complexity in the schema (and the consequently poor performance) was caused by the existence of tables created solely as artifacts of the OO design process - they reflected screen layouts, not data relationships.