对象关系-表关系
1 1对1: A - B
1 关联：A - B
1 A表中建立字段存放B表中的主键作为外键
2 B表中建立字段存放A表中的主键作为外键
3 A表中建立字段存放B表中的主键作为外键,B表中建立字段存放A表中的主键作为外键 > 按逻辑来看存在冗余，因为任一就可以建立关联，
4 3种方式本身都没有问题，从使用方便的角度上来说你怎么方便怎么来，但是是否需要考虑性能或者其它方面，这就是冗余，方便，业务，性能等等的取舍
2 一张表字段太多影响性能，所以拆出另外一张表
3 一个对象有两个或多个业务模块，按照业务需求拆成多个
2 1对多：A <> B
1 主表：主表是相对某种业务，属性而言，不管主表还是从表里每一个对象都是唯一的，重点不在于对象是一个还是多个，这里的一不是指对象的数量，而是指
重点在于谁可以领导多个，区别在于在这个业务和属性里，这个表是主导者，可以领导多个从属者
类比：10个人，每个人都是独一无二，但从某种属性而言，
里面可以有一个领导者-A，剩余9个从属者-B,那么A就领导9个B,A就和9个B有了联系，关联了他们
1 单体数据：查看某条数据，先看主键，然后找到它的从表，然后根据主键去找他所关联的数据
2 从表：某种业务和场景里，多个对象和一个对象存在关联
1 从表单条数据：也就是B表里某条数据，对象，属于A表里的某个数据，对象，主键
2 从表多条数据：也就是B表里某些数据，对象，同属于A表里的某个数据，对象，主键
3 关联：主表和从表里对象直接关联的建立
1 主表建立关联：
1 每多一个从属对象，建立一个字段存放从属主键 > 改表结构，明显不可能这样
2 建立一个字段，每多一个从属对象，把从属对象的主键，拼接到原有从属对象里 > 维护麻烦，关联查询的时候更麻烦，任何操作都具麻烦
2 从表建立关联：
1 建立一个字段，存放主表对象的主键 > 没有特殊需求不需要再维护，查询简单
4 问题：如果用领导者和从属者来解释，为什么多的一方不可以是领导者，多个人可以使用同一个奴隶？
1 所以这里的主导和从属，只是我主观理解他们关联关系存在的一种具体场景和模型
2 事实上这只是关联关系的一种模型，本身没有任何属性，你应用和理解在某种具体场景里就是某种关联关系
5 原因：我们只能理解我们所理解的，概念本身无色无味，只有在具体场景里才有具体模型，才是我们能够理解的
这也是我们理解概念的一种方式，反过来说也是提炼一种概念的方式
概念本身就是从某种具体场景里提炼出来的，那么也应该放在某种具体场景里去理解它
重点不在于你的模型更贴切，更对，更好还是我的就是错的，可能任何一种模型都不可能描述它的全部，又或者任何模型都能诠释它
重点是那是你所熟悉，所认识，所更容易接受和理解的模型吗？而是你能否借助这种模型真正理解它
结论：一对多，本身没有主从关系，但是现实生活中基本都是这样可以解释
3 多对多：A《》B
1 关联
1 A-B 里建立两个字段，分别存放A,B的主键作为外键
2 以B为主-在A表里建个字段存放B表的主键做为外键，以A为主-在B表里建个字段存放A表的主键作为外键，这样可以吗,A,B两表的合并不就是中间表吗？
模型：A1 A2 B1 B2 B3 ...Bn
1 A1,A2,都需要B1，A表为多，B表为单，那么应该在A表里建立字段存放B1的主键
2 A1,A2,都需要B2，A表为多，B表为单，那么应该在A表里建立字段存放B2的主键
3 A1,A2,都需要B3，A表为多，B表为单，那么应该在A表里建立字段存放B3的主键
....
n A1,A2,都需要Bn，A表为多，B表为单，那么应该在A表里建立字段存放Bn的主键
问题来了，如果每一个新增的B对象，都是被A表里的多个对象需要，那么A表中都要新增一个字段存放B的主键，这虽然能满足，但是项目还用做吗，天天就在建字段吧
总结：第二种方式理论上是可行的，实际上也是能做到的，但是只存在理论上，和一定数据量的情况
1 每新增一条数据就去对方表新建个字段维护
2 每多一个从属对象，把从属对象的主键，拼接到原有从属对象里
3 如果是一对多的关系里这样可能只是麻烦，还能实现，但是在多对多的关系里，这样就是灾难，数据量大到最后，每新增一条数据，你可能要话100年时间去维护它
4 换句话说如果少量数据，数据不再改变，第二种方式更好，因为从需求满足便捷上来说，单个需要方，只需要知道自己有哪些数据，在自己表里一眼就能很清晰的看到
别的有多少人需要多少东西，和单个需要方有什么关系，实现者有多少工作量，怎么实现，和单个需要方有什么关系
重点是这里单个需要方式开发者，实现者也是开发者自己,开发和实现都是开发者自己来做，自己不管自己的死活？
所以就需要有一种更合理，高效的东西来实现这件事，也就是对的方式，错的方式，也就是可行，不可行，能这样做，不能这样做
2 A-B:中间表，关联关系表
1 A-B 只描述关联关系，没有其它任何业务
2 A-B 不仅描述关联关系，A-B对象的组合会形成一种新的具有业务意义对象的C，那么就需要有其它业务字段
1 模型：1 A-B 从中介的身份或功能，转变或升级成为了开发商，本来是提供服务者，转变成生产服务者
2 A-B 从仓库变成了工厂，本来是堆放零件的地方，从这里组装成具体的产品了
3 中间表意义的转变，主要看是否有了具体业务的需求
3 A B C D E A-B A-C B-C C-D B-E
问题：是否存在 A-B <> B-E
猜测：如果A-B 有了业务含义，也就可以变成一个个具体对象 ab，B-E变成了 be，也是如此，那么理论上 ab 和 be 之间可以存在多对多的关联
模型：工厂模型：2 层，A 杯盖注塑机 B 铁块编号 E 杯体注塑机：杯盖生产批次 ab，杯体生产批次be，水杯生产批次
星期一：A1-B1,A2-B1 > 生产了100个水盖，10个不合格，E1-B1,E2-B2 > 生产了20个杯体 ，2个不合格
社会人际关系模型：6 层，理论上通过6个人可以认识世界上任何一个人
大脑思维模型：n层 无法知道，记忆关联关系组合，组成一个有思想的人，这到到底有几层想不到，计算不了
按照模型分析，理论上存在无限的多对多层数，但是实际生活中，我们只需要能够处理，1-3层就应该完全足够了，我觉得是这样，没有验证
因为我无法想到任何一种生产关系关联衍生超过3层的
结论：存在多层 多对多组合，但是实际生活中的任何业务都不会无限组合下去，1-3层就足够用
层数：层数就是业务的瓶颈，叠加一层，现实的公司体量会急剧变大，项目的编程也会大幅度复杂
4 单向多对多：A 》B
解释：具体业务中很多时候其实双方虽然是多对多的关系，其实是单纯一方需要另一方
模型：主题馆，商品，主题馆需要有多个商品，一个商品可以被多个主题馆需要
1 主要的主体从正反两方去看其实都是主题馆
2 当然这是有条件和限制的，只能说通常情况一个商品曾被多少主题馆展示过，这个需求很少有人关心，需要
没有需求那么也就不可能存在这种业务
3 某阶段的需求和业务，是存在单向多对多的主体的
4 单向多对多，就是单向需要
5 思考过程：A,B
1 两个业务对象A,B 之间的关系
2 以A为主想B，A是否需要，可以，存在多个B,如果没有就没有关系，有一个就可暂定是一对一，有多个就可暂定一对多
3 以B为主想A，B是否需要，可以，存在多个A,如果没有就没有关系，有一个就可暂定是一对一，有多个就可暂定一对多
4 如果双方都有多个就是多对多
5 不管A,B 之间存在何种关系都彼此为主都想一遍，简单粗暴
6 当然如果没有关系或者一对一，就可以一眼看出来，其实这个过程你也可以理解为思维过程中已经彼此为主都考虑的结果，
只是因为太简单，简单到你感觉不到这个变化过程，多对多的思维过程你就需要主动去做这件事