- 主题:python连数据库真的好复杂 那么多的第三方库是为啥
prepared statement 可以解决
【 在 flw 的大作中提到: 】
: 你听说过 SQL 注入吗……
:
--
FROM 52.9.227.*
是可以解决呀。
但 ORM 不就是干这个的？
【 在 hongyan2022 的大作中提到: 】
: prepared statement 可以解决
--
FROM 163.125.197.*
ORM 多了一层转换
就我个人的经历来说
一是工作量不大，虽然表可能有几十个或几百个，但每一个模块对应的往往也就几个；
自己转换的代码量很小
当表结构变化时，对应逻辑也需要变化，代码总是要改的
何况，还有测试
二是查询优化，或者把复杂的逻辑直接推给数据库，让结果直接可用。 数据多了，性能很重要，不同的数据库，不同的表结构，甚至于不同的语句，可能查询速度不一样。 用ORM ，这一层就全托付给别人了
【 在 flw 的大作中提到: 】
: 是可以解决呀。
: 但 ORM 不就是干这个的？
:
--
FROM 52.9.227.*
嗯，你可以自己写，但 ORM 用户觉得用 ORM 图个省心。
话说咋俩在 Python 版争这个干嘛，
选 Python 不就是图个省心吗？
我以前用 C 写的时候也是自己封装，封装来封装去等于封装出了一个私有的 ORM，
还得给人培训。
【 在 hongyan2022 的大作中提到: 】
: ORM 多了一层转换
: 就我个人的经历来说
: 一是工作量不大，虽然表可能有几十个或几百个，但每一个模块对应的往往也就几个；
: 自己转换的代码量很小
: 当表结构变化时，对应逻辑也需要变化，代码总是要改的
: 何况，还有测试
: 二是查询优化，或者把复杂的逻辑直接推给数据库，让结果直接可用。 数据多了，性能很重要，不同的数据库，不同的表结构，甚至于不同的语句，可能查询速度不一样。 用ORM ，这一层就全托付给别人了
--
FROM 163.125.197.*
哈哈，给本版灌溉一下。君子讨论，不叫争的
用python 是省心，是因为她简洁的表达，无数的库，能力覆盖从数据收集到统计图表显示和截屏的全部
写程序有两个极端
一是象perl 那样 写一次用一次
二是象Java 那样 写一次用十年
前者不考虑ORM，连个O 都没有
后者有ORM 的工具 -- 什么工具都有了，也不差这一个
python 的行文风格偏向前者，能力匹敌后者
适合高手的快速反应
O 可以是简单的 Dictionary，
或者DataFrame，更容易二维操作数据
M过程，也就是几行代码的事
【 在 flw 的大作中提到: 】
: 话说咋俩在 Python 版争这个干嘛，
: 选 Python 不就是图个省心吗？
: ...................
--
FROM 52.9.227.*
跟动态语言没关系
为了MVC，即使不说MVC，有了ORM就可以做面向对象嘛
没有object，很多东西显得乱糟糟
【 在 hongyan2022 的大作中提到: 】
: 一直不明白ORM 存在的意义是什么
: 尤其是在脚本语言里，或是动态语言里
:
--
FROM 124.64.233.*
那你写个object，里面放个 Dict就好了吧？
【 在 KeepHope 的大作中提到: 】
: 跟动态语言没关系
: 为了MVC，即使不说MVC，有了ORM就可以做面向对象嘛
: 没有object，很多东西显得乱糟糟
: ...................
--
FROM 52.9.227.*
那不就恶心了么
比如针对user的一个方法
比如用户传过来的明文密码，跟db存的hash做校验；又比如拿user id生成带时效的token
这俩操作都得去dict里取值，为啥不直接做成object的属性呢？
干活需要效率，这么搞是为了让同事没办法接自己的活吧
【 在 hongyan2022 的大作中提到: 】
: 那你写个object，里面放个 Dict就好了吧？
:
--
FROM 124.64.233.*
我代码里，用户的app module权限用的是db一个int值按bit拆开的
而前端看到的只是module1 true，module2 false，这个拆/装过程肯定是面对permission这个属性的
当然您也可以说，这permission是dict key不影响代码正常工作
那么，nice，弄成dict，对dict的属性做各种method
还得照顾对前端输出dict其他key时，像 password / permission 这种值要隐藏并用method计算后的结果来返回前端
最后这无非用更麻烦的办法，重做了一个只有自己看得懂的“类ORM”而已
【 在 hongyan2022 的大作中提到: 】
: 那你写个object，里面放个 Dict就好了吧？
:
--
FROM 124.64.233.*
老大，个人觉得，密码最好不要传明文的，就算是在https上，直接在页面上就腌了 -- 加salt
这样，自己的日志漏了，也没什么法律责任
obj.password vs. obj._data['password']
两个没本质区别
再原教旨主义一点，def getPassword：
那小小的一点区别也看不到了
【 在 KeepHope 的大作中提到: 】
: 那不就恶心了么
: 比如针对user的一个方法
: 比如用户传过来的明文密码，跟db存的hash做校验；又比如拿user id生成带时效的token
: ...................
--
FROM 52.9.227.*