sql在多本书中查找多个字符

我似乎找不到所有有特定人物的漫画。漫画和角色表具有如下多对多关系：

我的数据库架构：

**comics table**
comic_id
comic_name
comic_date

**character table**
character_id
character_name

**comics_character table**
comic_id
character_id

这对一个角色很有效：

sqlite3 comics.db

select comic_name 
from comics as c, comics_characters as cc, characters as h 
on c.comic_id = cc.comic_id and h.character_id = cc.character_id 
where h.character_name = 'Superman';

但是如果我想让所有的漫画都有超人和蝙蝠侠，我试着用这个：

sqlite3 comics.db
select comic_name 
from comics as c, comics_characters as cc, characters as h 
on c.comic_id = cc.comic_id and h.character_id = cc.character_id 
where h.character_name in ('Batman', 'Superman');

但这只给了我一份蝙蝠侠或超人漫画的列表，而不是蝙蝠侠和超人同时出现的漫画

我也尝试过这个方法，但没有返回任何内容：

sqlite3 comics.db
select comic_name 
from comics as c, comics_characters as cc, characters as h 
on (c.comic_id = cc.comic_id and h.character_id = cc.character_id) 
where (h.character_name = 'Batman' and h.character_name = 'Superman');

---

我尝试过其他变体，但无法获得期望的结果，因为您已经找到了一些原因，或路径不起作用-您为超人或蝙蝠侠获得了行，并且具有两个角色的漫画有两行，具有相同的漫画is和不同的角色ID。和路由不起作用，因为一行不能同时包含两个字符

因此，您需要使用或路径来获取包含一个或两个角色的漫画，然后还需要使用计数来仅显示包含两个角色的漫画。本质上，“过滤到超人或蝙蝠侠，然后再次过滤到仅出现在两行上的漫画ID”或“过滤到仅蝙蝠侠或超人，然后根据漫画is将其分组，并且只接受其中包含两个实体的组”。最后，这里的教训是，数据库行被视为不同的实体，当您想将它们视为一个实体时，您必须对它们进行分组，因此，在（故意）丢失组包含的实体的确切细节后，我们根据组的某些属性来识别漫画：

SELECT comic_id
FROM comic_characters
WHERE character_id IN (1,2) --Batman or Superman
GROUP BY conic_id
HAVING COUNT(*) = 2

=右侧的数字必须与in（）子句中的字符ID数相同。如果您在中对4个字符ID使用

，则使用
计数（*）=4

您可以加入其他表，以便使用名称等；我简化了这一点，没有多余的细节


脚注；这项技术将发现至少有蝙蝠侠和超人的漫画——漫画中也可能包含其他角色，但在我们组队之前，我们在WHERE舞台上失去了其他人。如果你想要只以蝙蝠侠和超人为主角的漫画，那是另一回事。为此，我们可以先分组，然后有条件地计数——给蝙蝠侠或超人打1分，其他人打10分，只有B和S的漫画得2分，只有其中一个的漫画得1分，任何其他人在场都会得到10分或更多，因此，我们可以筛选2
优秀的答案和解释-谢谢！这正如预期的那样：从漫画中选择漫画名称作为c，漫画角色作为cc，角色作为h在c.comic\u id=cc.comic\u id和h.character\u id=cc.character\u id，其中h.character\u名称在（‘蝙蝠侠’、‘超人’）组中，按漫画名称的计数（*）=2；很高兴它成功了！：）如果答案对你有用，别忘了标记接受/投票。我想说的另一件事；尽量使用显式连接语法，而不是用逗号分隔表名，即：
从漫画字符中选择漫画名称cc internal join漫画c ON cc.comic\u id=c.id internal join characters h ON cc.character\u id=h.id…
-这种语法是在20世纪80年代添加的，自那时起一直是推荐的。由于遗留原因，支持旧语法，但很容易出错，导致不可预测的结果