有做过连接oracle数据库的吗
报这个错 有没遇到过的
答:数据的仓库,如:在ATM的示例中我们创建了一个 db 目录,称其为数据库
MySQL的数据类型大致分为:数值、时间和字符串
用于连接远程服务器并执行上传下载
基于用户名密码上传下载:
基于公钥密钥上传下载:
# 对于更多限制命令,需要在系统中设置
这是一个创建于 572 天前的主题,其中的信息可能已经有所发展或是发生改变。
早年没靠谱 orm 的时候(暴露年龄了),点了太多技能点在写 sql 上,之后觉得所有的 orm 都很拧巴。。。 |
3. 速度感人,一个两万条记录的查询,用时三秒。 sql<100ms |
还有 django orm 如法实现分表。至少原生不支持。只能分区。 |
所以推荐原生 SQL ,还是 ORM 呢? |
该用 orm 还是得用 orm 毕竟方便。一直都用 sql 有两个问题,一个是预防 sql 注入,另一个是代码不易读。 |
sqlalchemy 怎么评价呢,首先说,功能完善整齐 然后就是 1 楼所说的,拧巴!没错!有的时候真行想自己去撸 sql 。。 orm 是一种思维和开发的负担。难写难维护难调试 你看,这里面包含了不含下划线全小写风格,驼峰风格,下划线风格三种 style 。真是玩死你系列。 |
Django 的 ORM 调优其实并不是很难,很多时候慢是因为用的不对(糟糕的 SQL 一样慢)。 当然,在极少数情况下还是会出现 ORM 无能为力的情况,这时候可以直接写 SQL 。 ORM 和 SQL 并不冲突。为了这 0.x%的情况而放弃使用 ORM 很没必要。 1. Django 的查询可以嵌入 SQL ,也可以把自己手写的 SQL 绑定到对象上。 不知道你遇到的具体情况是怎么样的,不过在我看来第一条应当是可以实现。 2. 有些表连接写出来是子查询,这个需要结合具体案例,不是很确定是否是写法问题。 3. 2w 条数据查询用时 3 秒,这个非常不正常,需要结合具体代码进行分析。从我主观角度看是代码写的有问题。 |
django 的 orm 其实挺好的。应付 90% 的逻辑没问题,读起来改起来都比 sql 容易太多。 |
sqlalchemy 硬着头皮用了一段时间,实在研究不下去,改用 peewee 了。 |
个人曾经想过把 Django 的 ORM 完全剥离出来,这样就可以脱离 Django 使用,后来看到 peewee 就放弃了... 不是说它做得有多好,不过至少是存在了. |
sqlalchemy 很多语言都有实现,换语言,换库都能直接上手。 |
1. Django 的查询可以嵌入 SQL ,也可以把自己手写的 SQL 绑定到对象上。 不知道你遇到的具体情况是怎么样的,不过在我看来第一条应当是可以实现。 django orm 是有 extra 的写法,不过我把这种写法归于直接 sql 一类。(也是我个人观点) 2. 有些表连接写出来是子查询,这个需要结合具体案例,不是很确定是否是写法问题。 3. 2w 条数据查询用时 3 秒,这个非常不正常,需要结合具体代码进行分析。从我主观角度看是代码写的有问题。 我的理解问题出在 django orm 在生成映射结构的时候多处使用 for 循环导致的这个问题。 |
不给 ORM 翻译出来的 SQL 就和裸 SQL 比较性能并猜测原因略有些耍流氓... |
单纯执行上面的语句不会执行 SQL 。 超过 1s 是很正常的,因为你要把所有数据一次性取出来。你可以用调试工具看一下,生成的 SQL 就是`select * from <table name>`,查询速度本身是非常快的,但单 2w 条数据,别的不说,单网络传输都要费不少时间。 使用 Django 的 ORM ,如果慢的不正常,用调试工具看一下生成的 SQL ,通常都可以解决。所谓必须写 SQL 的地方极少。注: - 部分复杂报表,查询速度慢,用 ORM 性能优化有些难做。 - 需要用到数据库专有特性, Django 不支持,需要用 extra 内嵌少量 SQL 。 |
SA 不适合初学者,以及一直用一种数据库的开发者。要驾驭好必须对 rmdb 有一定程度的认识,为了在不同数据库间充分利用他们的特性,并提供一致的接口, SA 没少下功夫,所以代码比其他 ORM 难读。 SA 不仅仅是 ORM 。 |
我只想说 SQLAlchemy 生成真正的 SQL 语句那就是灾难,性能的坑太多了。。。我觉得还是自己撸个简单的 ORM 比较好,我最新的项目就是这么干的, sql 执行效率杠杠的 |
直接手写 SQL 运行速度比 ORM 快很多 |
Django 的 ORM 事务和多库支持简直鸡肋。。。 |
超过 1s 是很正常的,因为你要把所有数据一次性取出来。你可以用调试工具看一下,生成的 SQL 就是`select * from <table name>`,查询速度本身是非常快的,但单 2w 条数据,别的不说,单网络传输都要费不少时间。 你的意思是说,(超过 1s 是很正常的)这一秒钟时间并不是 orm 引起的? |
要么是因为你水平到位了.要么是因为项目刚开始没多长时间.等将来业务变动自己撸的就扛不住了. 以为我这么干过.(逃. |
对 1s 很正常,和 ORM 没关系。 如果有 100w 条数据,你 list(qs)就不是慢的问题,内存会直接爆掉。 你执行 SQL ,实际上只是拿到一个游标,并没有立即将所有数据全部取出来。 你的 list(qs)实际上是一次性将数据全部取出丢到 list 里,不慢才怪。 |
我觉得任何 orm 都很拧巴。。 本来把多维数据放进二维的表就够受得了,完了之后各种 sql 查询特性还支持不齐。遇到一种新的子句就要看看文档怎么实现,不同框架还不一样,难受死了。 |
pep 没问题,但是你写 orm 语句就蛋痛了。 |
这里有一个不严谨的地方就是,我没有测试当前时间点 django orm 的效率. 最后还有一个问题,如果这种时间的损耗都可以忽略的话,大家所说的 ORM 影响效率的点在哪里呢? |
肤浅的认为 sqlalchemy 并没有 django 的 orm 好,是真的好难用啊,文档也乱七八糟的感觉,每次都得去看源码,有人用估计也是在不用 django 的时候 orm 方案上早期没有太多的选择,看了 peewee 的文档后觉得 peewee 的文档结构够清楚,明确的要求 connect 和 close ,很方便就实现了自动 reconnect ,轻松两行代码就可以做到主从的读写分离,用 pwiz 还可以把已有的表自省生成 model ,感觉使用 peewee 才是 python orm 正确的选择,还有 records 也不错的样子,暂时还没有在项目里用过,说的是 SQL for Humans :) |
有没有人告诉我,什么是拧巴 |
看到楼上有人说 SQLAlchemy 支持的 DB 更多, 先假定这是对的. 但感觉并没什么用啊. 一般应用数据库选型定了一种后很少会换, 支持主流的 MySQL, PostgreSQL, Oracle 就可以了吧, 再多也没什么用. |
哈,原来 peewee 用户挺多的 |
你好,想请教下 SqlAlchemy 的分表实现方法。 我现在是用 automap_base 来反向映射的表结构。 |
我也不会,只是又一次参加 pycon 年会的时候 达达的 rest api 负责人在做分享的时候讲到过. |
我自己写了 ORM 后,觉得不如 SQLAlchemy 功能多,于是我就用 sqla 了。但是 sqla 比我自己写的 orm 臃肿。谁让它功能多呢? 要记得,优化好了的 ORM 总是不如优化好了的 SQL 纯净语句。我曾经为了这个动了些脑筋。 |
Python 就应该统一起来。驼峰风格学习下 Java 什么的语言。这样大家都能迅速读懂。 可惜 python 的很多库写手,也许喝了瓶酒,写库的时候,命名非常不规范,反正发布了,能 work 就行。但是如果是大公司发布标准库的话,应该注意很多。 当然当年的 MS 的很多库命名也十分令人蛋疼。 |
2333 其实质量比较差的是标准库。。 |
你们好像忽略了 java 上的 orm 。。基本都得手写 sql ,也就是查询结果能映射一下。 优点是数据库特性支持的很好(废话),缺点是需要较高的 sql 功底。 |
咦。。。发现自己一年多之前居然回复过这个帖。。 |
你好,有关于你的单独剥离 Django ORM 的相关笔记吗? (星星眼)~ |
SQLAlchemy是Python编程语言下的一款ORM框架,该框架建立在数据库API之上,使用关系对象映射进行数据库操作,简言之便是:将对象转换成SQL,然后使用数据API执行SQL并获取执行结果
Dialect用于和数据API进行交流,根据配置文件的不同调用不同的数据库API,从而实现对数据库的操作,如:
这个功能只是优化在你写代码过程中,进一步优化
一般情况下,relationship跟外键在一起,当用显示存在obj.col这个方式的时候,我们一般叫正向查找,当使用backref叫做反向查找