这完全取决于你的口味，你应该使用哪一个模型。第二个模型的优点是你不会得到重复的。有了这两个模型，你可以得到一个查询的结果

select * from books
left join names auth ON (auth.id = author_id) 
left join names ill ON (ill.id = illustrator_id) 
left join names ed ON (ed.id = editor_id) 
where books.id = 1;

SQLFiddle给出了模型2的一个例子，如果你想从模型1中获取数据，只需将3个联接改为右边的表。
如果您想显示作者列表，我不建议将其作为新字段添加到names表中，而只建议使用联合查询。

select auth.* from books
left join names auth ON (auth.id = author_id)

只要在id、author_id、illustrator_id和editor_id上设置索引，就可以了。
编辑：我更喜欢Model 2。我认为它可能也会快一点：
1.数据库只需要打开一个文件（而不是3个）
1.表中的记录较少（与3个表的组合相比），因为没有重复项。
1.数据库只需要搜索一个索引集（而不是3个），并且可能会在后面做一些优化的事情，因为它在同一个集中搜索3个键（而不是3个索引集中的3个键）- * 这是我的直觉，不确定这是否完全正确... *

你可以在你提出的第二个设计中做一个修改，保留用户类型列，它描述了用户是否是作者，插画师和编辑中的任何一个。id将从0 - 7变化，你可以存储位数据的十进制值。如果一个人是编辑和作者，那么，

1(Editor) 0(Illustrator) 1(Author) => 5

因此，当您在该表上执行任何选择/搜索时，您可以在用户键入查询时添加过滤器。

例如，在以作者身份链接到某本书之前，是否需要验证作者是否定义为"Author"中的作者？是否需要查询以了解数据库中定义的所有作者/编辑/插图画家？
您已经在实体之间创建了N-N链接，但是在"Book"实体中有"auhorId"、"editorId"和"illustatorId"!
正确的方法是通过使用另一个表来解决多对多关系，最后得到如下结果

1. BOOK，具有ID、标题、说明等。
   1.参与者（所有人员的建议姓名），具有ID、姓名、个人简历等
   1.作者，具有书籍ID、参与者ID
   1.编辑器，具有预订ID、参与者ID
   1.插图，具有书籍ID、参与者ID
   1.或者，代替（3，4，5），BOOK_PARTICIPANT具有BOOK_ID、PARTICIPANT_ID、PARTICIPATION_TYPE（作者、编辑、插图画家的代码），或者甚至使用标志（IS_AUTHOR、IS_EDITOR、**IS_PARTICIPANT *，其中需要设置一个标志）
   如果您需要验证参与者是否为作者、编辑、插图画家，然后才能链接到书籍，则需要在此处向PARTICIPANT添加三个标志：作者、编辑、插图作者
   希望这能帮上忙