应用环境如下：一篇文章，本身可以有评论，每个用户都可以针对这篇文章进行提问，批注，并且其它用户可以针对某个提问和批注进行评论式的回复。 考虑到提问和批注的数量会很庞大，我觉得也用节点可能不太合适，所以想把它们处理成entity的方式，但是默认的comment只能对node进行评论。 不知对这个功能设计老葛您有什么好的建议方案呢？谢谢！ 论坛: 有问必答Drupal版本: drupal7 目前都是采用entity 目前都是采用entity reference，这样的解决办法，创建一个内容类型，作为评论，为其添加一个字段，entity reference字段，引用被评论的实体。 评论不与节点绑定，这个需求很早就提出来了，在Drupal8里面，有人在做这个工作，不知道会不会被包含进来，在Drupal8里面。 嗯，可是对批注和提问的评论也会是和comment一样，是多 嗯，可是对批注和提问的评论也会是和comment一样，是多级的，用entityreference的话可能会导致多层的引用关系... 感觉这个关联是有点复杂了 我目前是想直接去改comment模块那边的结构，加个entity type, entity id来实现comment对entity的，可能工作量会很大... 你可以为要被评论的实体，创建一个对应的影子内容类型。这样用 你可以为要被评论的实体，创建一个对应的影子内容类型。这样用户就可以对着对应的内容类型评论了。我们把这种评论，看作是对实体的评论，即可。 我把提问和批注设计成entity，而不是节点，是因为考虑不 我把提问和批注设计成entity，而不是节点，是因为考虑不要让node表太大，不知道你说的这个影子内容类型的方案，是不是在存储提问时，也要去存储相应的nid呢？如果是这样，是不是重复了两倍的数据量呢？ node表的大小，对于性能影响不大。 node表的大小，对于性能影响不大。
目前都是采用entity 目前都是采用entity reference，这样的解决办法，创建一个内容类型，作为评论，为其添加一个字段，entity reference字段，引用被评论的实体。 评论不与节点绑定，这个需求很早就提出来了，在Drupal8里面，有人在做这个工作，不知道会不会被包含进来，在Drupal8里面。
嗯，可是对批注和提问的评论也会是和comment一样，是多 嗯，可是对批注和提问的评论也会是和comment一样，是多级的，用entityreference的话可能会导致多层的引用关系... 感觉这个关联是有点复杂了 我目前是想直接去改comment模块那边的结构，加个entity type, entity id来实现comment对entity的，可能工作量会很大...
我把提问和批注设计成entity，而不是节点，是因为考虑不 我把提问和批注设计成entity，而不是节点，是因为考虑不要让node表太大，不知道你说的这个影子内容类型的方案，是不是在存储提问时，也要去存储相应的nid呢？如果是这样，是不是重复了两倍的数据量呢？
目前都是采用entity
目前都是采用entity reference，这样的解决办法，创建一个内容类型，作为评论，为其添加一个字段，entity reference字段，引用被评论的实体。
评论不与节点绑定，这个需求很早就提出来了，在Drupal8里面，有人在做这个工作，不知道会不会被包含进来，在Drupal8里面。
嗯，可是对批注和提问的评论也会是和comment一样，是多
嗯，可是对批注和提问的评论也会是和comment一样，是多级的，用entityreference的话可能会导致多层的引用关系... 感觉这个关联是有点复杂了
我目前是想直接去改comment模块那边的结构，加个entity type, entity id来实现comment对entity的，可能工作量会很大...
你可以为要被评论的实体，创建一个对应的影子内容类型。这样用
你可以为要被评论的实体，创建一个对应的影子内容类型。这样用户就可以对着对应的内容类型评论了。我们把这种评论，看作是对实体的评论，即可。
我把提问和批注设计成entity，而不是节点，是因为考虑不
我把提问和批注设计成entity，而不是节点，是因为考虑不要让node表太大，不知道你说的这个影子内容类型的方案，是不是在存储提问时，也要去存储相应的nid呢？如果是这样，是不是重复了两倍的数据量呢？
node表的大小，对于性能影响不大。
node表的大小，对于性能影响不大。