内容类型或普通的er表，这就是问题所在。

Question

我想知道，何时drupal开发人员应该使用普通的er表而不是新的内容类型？从来没有过吗？当预期的节点条目达到100 000时？我在谷歌上搜索了一下，没有找到好的答案。

使用字段数从自定义内容类型中选择非常耗时，因为所有的连接-S。如果您有5-10个内容类型，每个字段都有10个字段，并且期望有很多节点，那么是否应该忘记内容类型呢？

你在这件事上有什么经验？

Answer 1

如果您使用的是Drupal 7，而不是使用普通的自定义表，而是使用自定义实体类型，那么使用实体API非常容易--这为您提供了与视图和其他一些模块(如“开箱即用”规则 )的基本集成，而且自定义非常容易处理。

我不认为实体在普通数据库表之上有太多开销，而这些实体是不可部署的。我在一个拥有数百万行数据的站点上工作过，这些数据都可以作为实体使用，我们在必要时加载数千行数据，这确实需要大于128 so的内存限制，但我还没有看到内存使用量超过256 so，而同时在可能的数百万个实体中一次分页一千多个实体。(请记住，虽然实体是不可部署的，我们使用的是APC，这确实减少了内存的使用。)

然后，您还可以使用实体_元数据_包装器()的全部功能，这是非常棒的，并简化了代码。

基本上，实体为您提供了内容类型的好处，而不需要修改或注释的开销。事实上，节点是实体，分类法词汇和分类法术语也是如此。

使用实体API访问实体无疑是一个最佳实践，因为这允许运行所有适当的挂钩，例如从实体缓存中清除必要的数据。但是，您并不总是被迫使用实体API来访问数据库实体行，但是一定要注意，存在额外的风险，并且附带了这些风险。

Answer 2

这是个判断力的决定真的。如果您需要节点，请转到节点。如果您的托管公司愿意帮助您微调您的数据库，那么页面上每天有成千上万次点击量的数百次访问是可以接受的。如果查询计划器在最好的情况下工作，那么联接成本并不高，而且在开始担心之前，大多数内容都应该放在Boost缓存中。RAM中的缓存也是一个好主意。

另一方面，如果您需要记录一组不完全是内容的数据，可以使用自定义表。例如，不需要在日志中有可编辑的字段。

如果您要为内容定制表，那么在几个月和几年内，您将丢失一些为节点提供的内容。因此，您将实现解决方案，重新发明车轮。你可能会遇到一些像核心节点一样复杂的东西，但是不受支持，也不是万能的。