麻烦， 一本书，她的封面和信息能不能变，一旦变了，id就变了。id变了书 都要变。 所以创建书的时候，啥信息也不写，就是创建。然后这个id就是 索引作用。他的封面要二次索引？这太麻烦了。。。。有没有什么好的方案呢 ？
Discussion
replaceable event 为什么会有这个问题？是不是使用的方式不对
用eventid作为 bookid，所以就会这样。 书的所有章节 如何知道是这本书的，都是通过eventid关联的。
如果“书”是一个可变事件，就不应该使用 event id 做关联
“书” event:
kind: 3xxxx
d-tag: booka
// 其他信息……
文章 event:
kind: 30023
d-tag: booka:a
A-tag: 3xxxx:pubkey:booka // A-tag 是参考 NIP-22 的定义
d-tag: booka 这里有个问题要求是不重复的书，如果很多人建立书，不重复 我就想用eventid挺好的，结果。。。现在知道了这个问题，如果当初设计为uuid 也可以。 当然如果专门解决这个问题用一个空事件来产生一个eventid 也可以的。
只是最初设计的时候没有想到这个问题。现在的方案基本是类似的，修改后记录老的eventid（就相当于用了他的id功能了），
d-tag 不存在多人导致重复的问题，它是跟 pubkey 的。空 event 还不如 uuid
那么用户需要自己命这个 d-tag，也就是创建书的作者来写d-tag ？之前eventid比d-tag方便的点，就是eventid 在写书，展示书的时候 一次索引就可以，如果用d-tag是不是需要2次索引。
其实我还有另一个疑问，我之前发30023,发现d-tag 是5，6位数（含字母），那么是怎么保证 这5,6位不重复的呢？
谁来命名 d-tag 不重要，你可以用 title + 随机字符串生成 d-tag，也可以直接随机字符串。五六位的 d-tag 可以包含多少个事件了😂 一个人不至于产生那么多文章吧，觉得不保险可以加多几位。
我不太明白你说的两次索引是啥意思，有 kind, pubkey, d-tag 就可以直接找一个事件了