与用拼sql相比，快多少比例
非关系性数据库没有研究过，就关系性数据库而言，不觉得在性能方面有任何差异，任何一个客户端和数据库服务器交互，都会通过经过编译，解析，执行，返回结果集（根据数据库设计有所不同），除非orm实现数据库的协议绕过driver的基本检查，否者怎么可能orm快到哪去？只是方便抽象而已，个人观点，请指正！ From Noder
ORM仅仅和SQL比，其实没有多大优势，SQL仅仅是ORM最核心的功能。
ORM的功能通常如下：
- 对象CURD
- 对象一、二级缓存
- 对象的字段合法性检查（包括单个字段和字段之间）
- 对象修改日志
- 可选的缺省CURD WEBUI操作功能，自动和生成模板代码供修改
- 很多其他功能。。。。
所以ORM和SQL比其实不是比查询语法而已。
当然我曾经见过最牛的SQL程序员，连网站都是用PL/SQL做的。。
@chenxiaohu 那位使用PL/SQL做网站的牛人是个疯子。那个网站得多难维护呀。
我正在使用 Sequelize + umzug +Sequelize-Migration-CLI做数据表的操作。每次改版，数据表结构的修改，并不是 向Devops提交SQL脚本，而是在工程代码里多打包几个Sequelize-Migration文件（对数据表结构的修改“与回滚”逻辑都在这些js文件里实现 好了）。新web app在server端启动之后，Sequelize-Migration文件会被自动执行。整个对数据表的修改过程对devops是透明的。当然，devops也能够通过命令行，进行数据表修改的回滚。命令类似于：./node_modules/.bin sequelize db:migrate:undo
技术细节请参考：http://docs.sequelizejs.com/en/latest/docs/migrations/
@stuartZhang 我请教个问题，我之前用sequelize来操作mysql，取出的DateTime类型的数据都带有时区信息（类似：2016-11-01T05:27:42.000Z），怎样才能让DateTime类型数据显示成"yyyy-MM-dd HH:mm:ss"这样？
@DestinyInHand http://docs.sequelizejs.com/en/v3/api/sequelize/
Sequilize 可以配置它的timezone, 看它的描述, 应该是可以配置format的, 我目前用的配置是
timezone : "+08:00"
@DestinyInHand 我在项目里，数据库内仅只保存UTC时间（time zone 是0），所以，我之前没有考虑过把数据库内的时间进行格式化的问题。然后，从数据库取出的UTC时间直接被透传给前端。最后，在浏览器再把UTC时间转成本地时区内的时间。时区之间的Date转换，我这里都是在前端完成的。 如果后端有涉及到时间比较的业务逻辑，我这里的server代码也都是使用UTC时间进行比较。后端统一时间至UTC，我感觉能够降低由时区问题造成的复杂度。最终，所有和时区转换相关的问题就都抛到网页里完成了。
@stuartZhang 首先谢谢你的指教，因为我通过sequelize来取mysql中的数据，在前端以折线图的形式展现，有时会展示几千条数据，那么在前端对每条数据进行Date转换，会不会降低前端响应效果？
@stuartZhang 有什么难维护的。。。熟悉就好了。。。而且快，以前IBM 有个方案就是webservice ＋ pl/sql ＋ C++…速度与性能并重的。。。。唯一问题就是需要有相关专业人士具备就可以，目前C＋＋写的好的人不多，PL/SQL 写的烂的人太多。。。呵呵。。。不是维护问题，而是人的的问题，有什么人用什么工具，所以java 满大街。。。。用不好工具，是人的问题，不是工具的问题，。。不是SQL问题，而是你永不好，不要怪工具难维护。
@DestinyInHand 那前端需要预先通知后端：前端所在的时区，然后再在后端做转换了。要不然，后端预定的time zone可能与前端实际的时区不一致的。比如是，服务器在北京，但是，浏览器运行的机器的新疆。北京与新疆就差了几个小时的时差。
@stuartZhang 忘了很你说，在这些项目中，有一个团队，是专门制作辅助工具的，自动化生产工具，自动化测试工具，各种脚本支持的。。。不是想象的那么原始，而且还有各种中间伪代码中间产物。。。。你看到的C++代码，很多都是自动化产物。。。。鼠标点击出来的，然后开发在上面修改几下。。。。所以，效率啥的不是问题，只要有足够的能力，比如上面的loopback 也是，配置一下。。。 我自己是在自己的sql 外面做了自我包装。。。所以，写个数据接口，也就是配置一下文件。。。
