非Mysql数据库 慎用ThinkORM
公司OA系统开发时 技术选型用了ThinkORM
ThinkORM也算是国产的老牌ORM了 上手门槛比较低 文档也比较完善
一开始 公司业务数据库只使用了Mysql 所以体验下来还行
后续 公司因业务调整 接入一些第三方的数据库 如MSSQL(SQL Server)、pgsql(Postgresql)
开始发现一些问题：
复杂查询场景 下 非Mysql驱动 容易出各种奇奇怪怪的错误(如:存储过程、子查询)
这些错误在 Mysql数据库场景下是遇不到的
在使用pgsql的时候 你还要去vendor 找thinkphp官方包下面的pgsql.sql 然后手动把驱动函数导入到pgsql数据库中才能使用这个ORM驱动(
得出结论：
ThinkORM 对Mysql支持友好 但是其它数据库表现力一般 甚至差劲
如你的项目中可能会穿插其它类型数据库的项目 请慎用
~~有人可能会说官方的链式函数支持不好 那么你写原生查询不就好了
如果复杂查询全自己手写了 我还要ORM做什么 不就是为了提高项目的可读性 降低心智负担？~~
后续 我改用了EloquentORM 也就是laravel的数据库
目前整体使用下来感觉不错 即使在比较复杂的查询构筑下 也未产生较大影响的问题
不愧是laravel
遗憾的是 这个问题我发现的太晚了 我前期用thinkORM搭建了太多业务模型和服务
再想统一ORM将会带来很多工作量 现在就是项目里跑两个ORM 各自有自己的一套模型和服务层😩
635 8 0
8个评论
guchen
400
积分
0
获赞数
0
粉丝数
2023-06-09 加入
其实你们技术选型问题，既然都采用新技术pgsql首选用laravel的ORM。Laravel的ORM时刻都在更新，最新Tp的新版本bug太多了。我都放弃用tp框架了。
因为以前公司数据库只有MySQL
后面公司买了一些系统做接入(无接口，直接开数据库
肯定首选laravel的周边包，不是厚此薄彼，国内需求、使用程度远远比不上国外，没啥人使用自然也发现不了问题。
正确的
TP bug多 还是使用 laravel 的包 你看群主 就用 laravel 的包，tp的包很多都是野生的
确实 我自己在开发中也遇到过好几个
tp的验证器，出现很多问题，第三方库，已经放弃维护了
我现在就用的tp的表单验证器 ，不知道 应该用哪个替代了
workerman/validation 这个挺好用的 我现在项目就在用这个 没有出过什么问题
还好我机智，直接用的laravel的orm
已弃坑thinkORM
我们老大要求陆续过渡到
webman同时接触go周边。啥意思？tp lv满足不了你们的需求了？？？
不是因为访问量有多大。只是有些功能需要常驻内存，用webman更方便。
哦哦，有长连接需求呗
其实也还好 之前用TP处理sql server 写个 分页存储过程就好了 不兼容的 要么存储过程 要么写适配.
对 是存储过程
我都不用thinkorm，用个模型关联都能出现一些奇奇怪怪的问题