sfree2005

写全新功能的时候用还差不多，如果现有的都要改那就太那个了。 话说你为什么不喜欢 graphql ？ 我觉得挺不错，type 类型从后到前， 不容易有 bug ，文档也清晰。

@dalaomai @MakHoCheung viutv worldwide 的油管频道就可以看，官方的

实话实说，很有诚意

没有绝对安全的，毕竟你做得网站就有一部分东西肯定是公开的。除非你网站没有什么特别重要的东西，实施行业一般标准的安全规则就行。别人要黑你网站也要有动机吧，只要破解一般的安全规则的成本高过你的资料成本，也就没有黑的动力了。

那边有什么化妆品的连锁店吗？网上有 gift card 卖吗？买一张给她让她自己去选化妆品咯。看上去好像和给钱差不多，但你毕竟还是用了心思去查什么化妆品店质量好。

@newtype0092 他的理由和楼上的说的差不多，就是扩展性好之类的，但我觉得有点设计过度，可以一对多的时候就一对多。而且有些关系永远是一对多的，例如 created_by, 多对多我感觉就是需要的时候再用。

@mmdsun 但我觉得 如果外键字段多更需要一对多的，而不是多对多。 获得每个外键的信息的多对多查询更复杂，每个外键都更复杂一点，那更多的外键不是让查询变得更复杂， 性能更低了吗？

业务没有让用户删除订单的功能，只能是归档。毕竟都是钱的东西，怎么也要多方留个底。

的确不能保证某个外键永远一对多， 但 orders 表里用户相关的外键肯定有永远一对多的，例如 created_by 这样的外键。 我的意思是不能允许 orders 和 users 只能是多对多， 一对多的也可以同时存在。

Laravel 会根据网站设计写 API 的时候 TDD，感觉这比较符合逻辑。你知道要有什么输入和输出才能去写怎么实现。