微信扫码登录
| 标 题 | 时 间 |
|---|---|
| Eloquent ORM 的编程思想 | 06:06 |
| 必要的准备工作 | 04:54 |
| 一对一关系映射 | 11:15 |
| One To One使用自定义的关联外键 | 02:23 |
| 一对多关系映射 | 09:03 |
| 面向对象的方式绑定一对多关系 | 06:25 |
| 使用自定义关联字段绑定一对多关系 | 04:14 |
| 一对多关系映射中的SQL语句 | 07:30 |
| 多对多关系映射 | 10:12 |
| 面向对象的方式绑定多对多关系 | 04:55 |
| 访问多对多中间表中的数据 | 05:00 |
| 为多对多关系自定义关联字段 | 02:25 |
| HasManyThrough对象桥接式穿越关联 | 08:54 |
| 为HasManyThrough自定义关联规则 | 03:26 |
| 多样化的一对多关系映射 | 05:59 |
| 多样化一对多实现方法和数据伪造 | 11:50 |
| 如何绑定对象的多样化一对多关联关系 | 05:24 |
| 多样化的多对多关系关联 | 15:55 |
| 关联关系中关联对象查询 | 03:49 |
| 关联对象提前加载和延迟加载 | 04:28 |
| 标 题 |
|---|
现在公司主管明令禁止使用关联关系，发现根据主表记录获取对应的从表记录好痛苦，用scope也不太科学，找不到更优雅的解决方法了
你们这是啥主管，这么僵化，我们用的数据库就是关系型数据库，无论用原生语句还是封装后的ORM操作，本质上玩儿的就是关联关系。干脆也不让你们用关键外键得了。我很好奇你们做项目主管的出发点是什么？
拆分服务，把数据表按照业务进行划分，怕某些Model 因为关联关系过多，而导致文件特别庞大
那我就不吐槽了，只是因为担心你们就这么制定方案不是技术人应有的态度和职业素养，不同数据库下的极限测试如果都没有进行就这么定方案，那这主管就真的有问题。
数据库极限测试怎么做？
这个内容不是对数据库单独测试，而是结合业务和框架的测试，是前期选型要做的事情，不管商用的数据库还是自建数据库的测试，这个没有统一或标准测试流程，根据业务来的，是你们主管应该做的事情，对成本，效率等综合的一个衡量。
还是你们太听话了，我以前在公司的时候，解决方案基本都是我制定，台湾区的，韩国区的从来都不会推翻我的方案。