比如做一个魔兽世界的公会，

第一个表是整个服务器的公会列表，

假设有一千个公会吧，

然后每个公会又有一百个人，

那么请问怎么做呢，

难道先做一个公会表，

然后再做一千个小的表格吗？

有了公会id还要公会表干啥……除非另外要存一些公会信息啥的……

两张表，公会表和玩家表，玩家可以保存一个公会id的字段

10万的数据还不需要分表

1000万再考虑吧

你这不是mysql问题，你这是关系型数据库的问题
请自行查询关系型数据库的范式概念

楼主学了那么久it，能问出这个，确实是天赋太差

真心建议你放弃吧，你没有学习的天赋

恕我直言，感觉这是一个钓鱼贴……

你觉得这贴能叼什么鱼？

Many to many，三个表

真的要三个吗，我看了回复想了想，好像两个也行，

只不过，我们游戏里面其实加入公会的可能是少数，所以每个人都加好多列感觉有点浪费，

不知道会不会影响效率

三个表逻辑上简单明了而且没坑。你的用户表不需要改动，加一个table关联用户和公会。你可以网上借鉴一下学生和课程数据库设计，基本类似。基本就是16楼的建议。以后比如做列出某公会玩家，两个表和三个表性能会差很多，如果公会玩家很少。你可以本地测试一下。

本帖最后由 tgmj001 于 2019-6-1 05:01 通过手机版编辑

不会是想把公会的一些信息放在玩家表里吧？那样是很差的设计，比如玩家表里有id列, name列,公会name列等，那样不好。如果只加公会id列也不如三表设计。

本帖最后由 tgmj001 于 2019-6-1 05:35 通过手机版编辑

短期看问题不大，如果是学校作业或个人项目用完就扔可以的。长期的话用户表会爆炸，信息太多，各种问题。如果能用就行可以两个表，如果想同时学习一下建议三个。

本帖最后由 tgmj001 于 2019-6-1 06:07 通过手机版编辑

魔兽有私服 有代码的有数据库自己下个研究一下就好了呀

完全范式化设计是为了降低数据冗余，使得entity之间关联逻辑更加清晰

但是会导致过多的table join，性能不一定更好

整体业界从database join to HTTP join，应该问题不大。主要还是一段时间后用户表的column会越来越多。

本帖最后由 tgmj001 于 2019-6-1 08:02 通过手机版编辑

Posted by Xiaomi MIX 2S
按楼主的描述直接一张大宽表算了，反正看描述楼主也不懂，肯定不是公司项目

你看这个表它又大又宽。。。

小规模区别不大

用户表加个字段：所在公会id，少一个表简洁点