使用 ORM 时，在数据库设计中需要注意哪些事项

Question

当您知道将使用对象关系映射器 (ORM)维基百科访问数据库时，需要注意哪些数据库设计问题？另请参阅实体框架 NHibernate 或 LLBLGenPro。

例如，我将注意 SqlServer 的 RPC 调用的 2100 参数限制。当使用 LLBLgen 并在使用复合主键时连接表时，这是一个问题，请参阅复合键的 MSDN 文章。

Answer 1

通过标准规范化技术，主要是第三范式。某些 ORM 可以获取在数据库级别定义的关系，因此您不必手动进行。

我真的会反其道而行之，问我应该对 ORM 了解些什么。确保您知道： - 如何分析查询？- 如何覆盖 ORM 并编写自己的查询？- 我可以使用存储过程吗？

数据库应该是 ORM 不可知的，因为它很可能会比应用程序更持久。

Answer 2

永远不要让 ORM 创建或更新架构。始终使用其生成的 SQL 作为模板，但在进行更改之前要经过它（我已经看到我们的 ORM 制作了冗余索引，使用了错误的数据类型......所有这些糟糕的东西）
请注意您的 ORM 不能做什么。Django 有一段时间不通过 ORM 支持 group by，这很痛苦（仍然是，遗留系统很有趣！）。因此，即使 DBA 不是为 ORM 编写代码的人，也必须意识到 ORM 的局限性
定期抓取你的慢日志，通过 mysqlslowlog 聚合它们，然后查看前 10 条左右。基本上它会向您显示总体上花费最多聚合时间的查询。一个平均只需要 1 秒但在过去一个月内运行了 50K 次的查询会像拇指酸痛一样突出在该汇总报告中；)

我不会说极端到完全转储 ORM。如果使用 ORM 的开发人员不是 DBA，那么他们编写的 SQL 可能与 ORM 一样糟糕或更糟。因此，最终将由 DBA 来观察发生的情况。

Answer 3

关于遗留数据库，我立即注意到一些事情，它不同于由 ORM 创建的数据库，如Sequel和ActiveRecord for Ruby。

我多年来一直手工编写 SQL，因为我不信任 ORM，但在过去的两三年中，我开始使用前面提到的两个 ORM，并且对它们与现有数据库的集成程度印象深刻，以及如果遵循他们的约定，他们可以如何破译数据库，或者我花时间为他们提供理解遗留数据库所需的提示。

我不知道是否有设计模式以与 ORM 配合使用的通用指南，但我认为我们都会从一些标准中受益。ORM 肯定是有时间和地点的，特别是如果您使用的是好的 OO 语言并且您的日程安排很紧。