这个看起来没有了，left join 最后给你的变化也就是个写法上的差异，现代关系数据库优化后和你写的这个子查询基本没差异。
这个限制在于后面那个 in 里面如果是常量，可能会由于列表增加而导致 SQL 语句长度超长....

从基本假设开始吧:
所有的用户都要有:用户名 /密码
供应商要有提供的服务和产品，要可以收钱
工人要有所属的供应商或者可以独立运作，工人要有单位时间工资。
客户要可以付钱

所有的设计都要围绕业务场景。我们假设业务场景如上描述，就这样了。

那么我的建议是用户表要有一个。这个表只存放大家都要有的字段，例如用户名和密码(当然要有 ID)。那些登录之类的，就可以只使用这个表来进行查询。
供应商则是关联到用户的另外一个表，可以有一些其他的属性(例如收款账号)和相关的信息，还可以关联到产品和服务。
工人和客户是第三、四个表，思路类似供应商。
后面的表都要有一个字段(一对一)关联到用户表，你可以直接使用用户表的 ID 字段当作后面 3 个表的主键 ID 字段，后果只是后面 3 个表的 ID 看起来是离散的。
但是我仍然建议要有独立的 ID 字段。

楼主....额.....有些话不能说。

vuepress，这个东西很好用

我知道有一个这样的网站，但是我不会在这里说

这个游戏看起来应该翻译成:"不文明".....

我也不回。

在下在大学的时候参加过一次 IQ 测试，结果是 68。
我后来以为是个例，就把同屋的 6 个人都叫去测了一遍，大概最高的也只有 83，大部分都跟我差不多。
别问我是啥大学的......

你在表 1 中必须有个 mobilephone 字段才能插入......
有了的话就很简单了，写个 left join 语句往 1 表插入就行。
如果不会写 SQL，就写个程序把二表的数据读到内存里，一个个往表 1 插，每次插入之间检查 userid 是不是在表 1 就行了。

你不太可能从数据库查询 100 万行数据到前端页面，这和前端页面显不显示似乎没什么关系。

我没见过 JSON 用一个可变的值当成 Key 的，所以 A 的写法格式上不能说错，但是这种写法很难形成一个稳定的格式，因为解析这个东西的假设是第一个属性的名字(key)实际上是某个(不存在的)属性的值。一旦发生针对这个的变更，后续的所有客户端的程序可能都会受到影响。
因此，我推荐 B 的写法。

我就觉得这个名字无比牛逼....统一操作系统.....

正常应该就是代码处理，SQL 处理这个非常费劲。并且思路和代码是一样的。

这个应该是个占位符，实际使用的时候需要将这个{0}替换成实际的值。

在关系数据库出现之前，我估计世界上所有的数据都是用固定格式的文本 /二进制文件存储的。
那时都是在代码里判断唯一性。直到关系数据库出现......

首先我建议遵循 ERP 的数据结构，产品基本上就是 BOM，BOM 其实不关心你生产的是汽车还是服装。需要细分属性的时候就建表扩展就行了。其实我之前实践过用 K/V 的结构存储不同的属性，但是这么做的问题是有一些需要经常查询的字段，可能必须拿出去单独建表，不然无法保证性能。
其实，首先需要评估的是你做这个东西干啥，然后再考虑 IT 实现。

需不需要分别建表完全取决于这个 Banner 要怎么用。
例如你分析的结论是同一个 banner，对于所有的对象都是一样的，当这个 banner 发生变更的时候，机构、课程的 banner 都要跟着变，那就应该建 banner 表，否则就需要分别建表。

Markdown 的渲染大部分都是不管顺序号本身，只比较大小。