@kukuwhu 说出了真理， RMDBS 可以是对算法的依赖变成了对 DB 的依赖，当然， DB 本身已经是一个集算法大成的系统

@Amit 能使用你的浏览器已经属于社会工程的安全入侵问题，也不是服务端的设计能控制得来；无论session还是cookie还是token，在实际生产中都会控制超时，https只是提升安全系数，不是杜绝安全隐患。安全不是一方做得万无一失就高枕无忧，就好像，银行安全系数再高，被别人偷看了密码还是能把钱取出来是一个道理

首先，cookie 与 session 是息息相关的，session的标识是通过 cookie 的固定 key获取，比如 session_id 或者 jsession_id 等等，现在很多框架都会帮你实现隐藏的 session 功能。但实际上，在标准的HTTP协议上，根本没有我们所谈论的 session，session 是基于 cookie 的一种HTTP状态维持实现(RFC2109)

其次，在很多精简的后端框架，压根是没有session这个东西，需要实现session，需要自己去写cookie，并且需要自己去序列化session信息保存，比如使用数据库，使用文件，使用缓存等等。而且写入cookie的key可以是你自己定义的任何值，比如 access_token、auth_token、abc或者任何你喜欢的

然后，最近我们做了一个项目，是完整的前后端分离，使用的方法是使用token验证，而且涉及到不同后端应用的反向代理，实现一个分布式的 session 不太现实，我们要求各后端应用的设计各自实现自己的类session状态维持，但实际上，这种设计是不合理的，http的优势反而是无状态。

最后，关于安全问题，除了增加无操作超时机制、多重验证的手段外，最能够防止 cookie 劫持的方法是使用 https。

希望以上信息对你有用。

@shyrock 自相矛盾的测试数据不就是 理论->实验->理论 不断重复修正的过程么，而你一旦实验测试，就会涉及到场景模型，单纯撇开模型或者实际场景先讨论一番理论，很多情况只是徒生口水仗而已

@lijianying10 还真有MangoDB额.....

@shyrock 事务本身的确是C的一种具现；

你的问题是mongoDB的缺点是？我的回答是拿模型去试试，理论这东西，有指导意义，但远不及实操的体会深刻。当你要自己去实现关联/限制/约束，还要考虑性能的问题时候，你自然而然会体会到所谓的缺点，缺点也是因场景而异的。当然，不是所有的应用都需要关联/限制/约束，所以mongoDB才有存在的意义。

首先，这里面有一点误导的是，CAP不是说，只要有A，就一定没P，而是究竟是A的优先级高一点，还是P的优先级高一点。好了，回到正题

一般而言，MySQL是传统的RMDBS，是以ACID为第一守则，实现分布式，CA成为首要优先级，这里的表述不是很到位，可以看看下面这篇参考

http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed/

所以，并不是牺牲什么为代价，只是处理事情的优先级的先后顺序，这个的使用还是需要结合实际生产应用。


再者，mongoDB跟RMDBS是完全不一样的东西，没事务，没关联，没约束，这些在实际的生产应用中可能会产生很多的问题，所以，mongoDB是那种看起来很爽，用起来就各种问题的存在。如果没有实际将模型拿去验证，又或者把SQL那一套塞进去的话，很多时候会得不偿失。

对于公司来说，当然是想开箱即用，在这种情况下：
1. 先理解一下DOM，这是所有前端的基础，语法什么的摆后面去
2. 使用原声的JS测试一些DOM的属性啊，获取节点等等，但不要深究
3. 直接上马学jQuery，边开发边学，这样很快就会上手啦，JS语法这个反而是可以后补的，而且一般情况下也用不上很多JS的黑魔法

PS: jQ跟Ng实际在设计以及开发的理念根本完全不一样，个人觉得，先搞掂jQ比较符合公司需求。至于Ng可以看成是进阶学习

可以使用SUM-IF来解决，例如：

SELECT
`姓名`,
SUM(IF(`课程`='语文', score, 0)) AS `语文`,
SUM(IF(`课程`='数学', score, 0)) AS `数学`,
SUM(IF(`课程`='地理', score, 0)) AS `地理`,
SUM(IF(`课程`='历史', score, 0)) AS `历史`
FROM 表名 GROUP BY `姓名`

重点是首先，课程的名字不能错，否则会统计不到，另外就是，如果同一张表中存在重复记录，会累加统计，所以，一般会加上其他限定条件，比如 考试时间，或者批次等等来区分

@helloworld00 竟然还有人继续啊