首先，要表面我的 2 个核心观点就是不推崇所谓的一上来就纯 sql 库给自己挖坑，然后第二个是不要过分妖魔化 ORM 。 所谓纯 sql 库比 ORM 更好本来就是伪命题，是自己给自己制造焦虑，制造痛点。软件工程的最后肯定都是为了更易用，更通用。正如为何要用 IDE ，直接记事本手撸不行吗，为何要用 GUI ，直接 command line 不行吗，底层对精细化的掌控的追求的确是好，但必有大的牺牲。这里把 ORM 想象为对数据库访问的辅助集合就能更容易理解，纯 sql 的调用，后期为了方便易用，最终肯定也会写个类似的辅助集合，活着活着，就活成了“别人的模样”。

有人说 ORM 里你看不到 sql 的逻辑，ORM 里能打开控制台输出具体执行了哪些 sql 的功能吧。有人说 ORM 的性能不行，稳定性不行，难道说开发 ORM 的程序员都是傻 X ，故意弄一个很卡，很慢，很不稳定的库出来？即使有部分逻辑性能上有问题，但一般 ORM 的库都提供了易于扩展的方式，然后你可以修改为你认为的高性能的方式即可。然后是 ORM 一般也支持直接 raw sql 的方法或函数，如果原生的查询满足不了，还能直接执行 raw sql 。

@lesismal 就像高级语言你不用，非要去用 C 语言，追求所谓的更好颗粒的控制，最后却本事不够，反倒遇到各种坑，写出的东西问题多多

@gam2046 ORM 其实可以理解为对数据库访问的辅助类，不管你怎么样，最终还是离不开自己构建一个方便的访问操作框架，所以一开始用别人现场的不好？功能不够的可以再加

@acehowxx 我个人感觉不应该一上来推崇纯 sql 的方式挖坑，就像要啥 vue, 要啥 react, 直接纯 js 写不香吗。别人对数据的访问封装库的存在就是解决数据沟通上的痛点，存在即有道理。

@lesismal 联查的实现是否会过于复杂，如果因为代码量过高又封装一个库出来，那不是当初不如直接用 ORM 库。然后还有个点就是这种模式上来得熟悉 sql ，join 之类的复杂的语句，别人 ORM 即使可能不太懂 sql 也能上来就用，出了问题然后再查询。再着是 sql 安全问题，ORM 库一般有封装解决这个问题，然后由社区抓漏洞，而如果纯 sql ，安全就得自己把握。

怎么处理关联查询呢

买毛硬件现在，现在天价

建议加组合索引，不建议加单独索引

win10 进程一般不管再小的程序都吃更多一些的内存已缓冲，后期程序多了再腾出来给其他应用

😁不出意外的情况，这篇文章马上将被站主移到水深火热节点

😀不出意外的情况，这篇文章马上将被站主移到水深火热节点

@codehz
为何胡说

@exceptionplayer1 然后因为国内网络比较垃圾，稍微拖点国外的东西，9、10MB 的文件都可能会卡壳，而 Lua 则最大打包起来不过 2、3MB，直接秒下，很快就部署起来了。

@ysc3839 我觉得不能这样说，因为 python 的实现复杂，所以嵌入也不一定完善，可能会出各种各样的问题，而 lua 的实现相对简单一点，嵌入的实现也更容易很更快的达到稳定

@mattx 是的，lua 写点小脚本或者缝合其他语言，或者缝合其他组件的确不错，轻量快速。

@jugelizi 常用的库都有吧， 还是不行，为何不用第三方语言实现，要用胶水语言

程序员最喜欢喊“改变世界”的口号

硬是没看懂干啥用的

鸡毛蒜皮屁大点事情这么在意