什么时候创建实体而不是仅添加新的内容类型合适？

与仅构建新的内容类型相比，创建新的实体类型有什么好处？

当您已经将所有CRUD和Views功能内置到内容类型中时，执行创建新实体所需的所有自定义编码似乎有点过头。

它所带来的好处不仅仅在于它所带来的好处，还在于它对您所说的特定情况的适用性。您几乎可以用节点表示任何东西，并且在99％的情况下（至少我已经发现），您无需实现自定义实体类型。

我一直认为taxonomy_term实体类型是为什么不是所有事物都应该是节点/内容类型的一个很好的例子：

分类术语本质上是用于将不同的实体组合在一起，因此不需要与节点相同的功能。从理论上讲，您可以使用内容类型来执行此功能（可能带有节点引用字段），但是分类法术语不需要执行与节点相同的操作，因此这样做实际上没有任何意义。对于user和taxonomy_vocabulary实体类型也可以这样说。

因此，将分类术语创建为一个单独的实体，并对其进行编程以仅执行其所需的操作，同时仍获得能够附加字段等的好处。

我认为，简单的答案是，当节点/内容类型无法满足您的需要时，或者只是大量的过多的杀伤/开销而没有什么好处，那么您应该选择编写一个自定义实体。

这仅基于我的个人经验；我很想听听直接参与Drupal核心开发的人对此有何评论。

我使用的一条非常简单的经验法则是，是否需要单独公开显示您的内容。如果是这样，则转到节点，否则请选择一个实体。现在，Entityforms允许您创建一个界面来填写您的实体。

例如，在使用D6制作的网站上，我们构建了一个广告内容类型（其图像字段，开始/结束显示日期...），但是您必须使其默认情况下不发布，并赋予编辑者编辑的权利。 / view这些节点，并希望任何视图/搜索都不会在外部显示这些内容。这很麻烦，与实体打交道也更容易。

实体代表特定的用例。

我相信这个简单的定义应该归功于Fago，但是我懒得找到参考。

如果愿意，我们可以在所有用例中使用Content（aka Nodes），但这通常没有意义。

Content 具有评论者和菜单位置的作者和设置。

Users表示一个用例，它与上述情况完全不同，Content因为user上述两种方法都没有意义，而另一方面，user必须具有电子邮件和密码。

Taxonomy terms 之所以能脱颖而出，是因为它们具有内置功能，可以按层次结构甚至是圆形结构进行排列。

如果您的用例与现有实体足够相似，请继续使用该实体。但是，如果您的实体所受的规则不同于任何现有规则，请创建一个新规则。

还有一个《实体简介》，但是很遗憾，它并不能真正回答您的问题。

我认为这完全是关于上下文的，一个节点主要用于内容，因此是博客，文章，常见问题等。而用户使用诸​​如员工，客户等个人资料。何时可以创建新实体的示例：

• 论坛
• 项目（就项目管理而言）
• 形成
• 支持票
• 组

虽然您可以将节点用于支持凭单之类的东西，但它可能不是最佳模板和默认值……希望能有所帮助。

创建实体所需要的开销比节点少，因为它们不需要具有实体具有的所有繁重功能。

这也意味着存储可以更简单-如果需要，您可以构建它们以在没有JOINS的简单查询中获取所有信息。所有字段都很好地放在一个整齐的表中。

如果您有很多功能需要对实体进行查询，并且要同时更新许多实体，同时对数据库执行UPDATE查询，那么这将是一个巨大的好处。如果您可以确保数据相对独立地包含在单个表中，那么您的担心和数据损坏的可能性就会减少。

内容类型被设计为网站内容。也就是说，每种内容类型都旨在发布并出现在网站上。例如，文章（开箱即用）被设计为出现在第一页上。

现在，假设您要创建诸如工作或公寓申请表之类的内容。显然，您不想在您的网站上发布某人的就业申请。另外，如果您要建立客户/潜在联系人列表，该怎么办？您是否想借此机会将这些信息错误地发布在您的网站上？就我个人而言，我不会。

因此，上面讨论了实体表单模块。它允许您创建一个不被设计为内容的实体类型。但是，这些实体类型可用于支持诸如规则，视图和有机组之类的实体的任何模块，仅举几例。

然后进入产品实体类型的Drupal Commerce。基本上，实体使开发人员能够以原始Drupal设计师无法预料的方式扩展Drupal。

这有待讨论，最终您必须以开发人员的身份做出决定。

每当数据不应该公开使用其自己的url时，我会选择节点上的实体。默认情况下，节点将获得url别名，发布状态，标题，元标记等，而实体仅在数据库中获得一条记录。

“我希望能够在文本中添加尽可能多的横幅，然后在博客文章中选择其中一种”

• 内容类型为“博客”
• 自定义实体将是“横幅商品”

实体与内容

实体具有 实体束，其中实体束具有 字段

内容是实体的一种。所以，

内容具有 内容包（文章，页面），其中包含 字段（正文，文章图像）

如果您是程序员，则一定会选择创建自己的实体的路径，但对于Sitebuilder而言，这并不是最佳选择。再次为网站建设者提供了用于创建实体的UI http://drupal.org/project/eck