@q397064399 所谓穷举无非就是穷举每个物品取或者不取的所有组合情况。
对每个物品而言，取或者不取意味着具有 2 中不同的状态，
所以如果有 n 个物品，所有状态的组合自然就是 2^15 种，对吧？
穷举的实现方式就很多了，可以搜索，也可以枚举， etc. 就看个人的习惯了。

@q397064399 (a+b)^n 二项式展开一下就是你的结果，其中， a = b = 1

PS: 当然这个问题规模并不大，穷举的复杂度也不过是 O(2^15)

重温一下当年那个熟悉的递推公式：
dp[i][j] = max(dp[i-1][j], dp[i-1][j-weight[i]] + value[i])
dp[i][j]表示考查到第 i 个物品且背包容量为 j 时，背包所具有的最大价值

http://tech.163.com/16/1207/12/C7MDUS1L00097U7R.html
老贾的这个年怕是不好过了

和 import.io 简单对比了一下，在页面异步加载数据的采集效果上还有待改进：
例如 https://item.taobao.com/item.htm?id=529572785771 淘宝商品详情页面的价格数据，
造数目前是没法采集到的，但是 import.io 是可以准确采集到的。

@shijingshijing 这话没毛病，咱们看热闹的不嫌事儿大，最终这道选择题还得楼主自己去做。

@Borden 这话就有毛病了，买京户还真是个事儿，而且往往是有钱也买不到的哦

@zyhao 这件事情的利害关系是这样的：
现在如果放弃了争取拿到京户的机会，那这辈子甚至下一代人可能都不会有这样的机会了。
但是拿到了京户就不一样了，只要自身实力过硬， BAT 的大门是永远向你敞开的。

@youshangdemajia 是的，出社会该考虑长远了。
因为你的决定很可能关系到你的下一代人在哪里生活，接受怎样的教育。

@pywilhelm 户口在中国人看来，最为重要的作用是关系到下一代的教育问题，就是小孩儿的上学问题。
没有户口在北京虽然也可以买房生活，但是小孩儿是没法儿参加北京高考的。

有了户口，剩下的就是钱的问题。
赚钱什么时候都可以赚，户口过了这村就没这店了。
还有楼上那些诟病北京空气问题的，想必更多的只是出于酸葡萄心理。
没有真正在北京生活工作过的人是没有资格评论北京的天气状况的。
我在北京已经工作生活两年多，平心而论是可以接受的。
难得那么几天污染严重，自身做好防护工作就好（室内添置空气净化器，出门戴上口罩）
最后祝楼主顺利拿到京户，这真的不需要犹豫。

3 楼的解法只能从一定程度上缓解题主的痛点，但不是这一类问题的根本解决方案。
这类问题其实是可以归结为同一类问题的，那就是如何高效的从海量关系型数据库中实时查询得到按需排序分页后的数据。以下的个人见解不提供完整的解决方案，仅供抛砖引玉，楼主可以之后慢慢探索优化方案。

众所周知，类似 MySQL 这一类数据库引擎，在面对海量数据（量级千万以上）执行过滤排序时，效率是很难令人满意的。一般的做法往往是，预先将候选数据集筛选出来加载至内存，然后再在内存中使用一定的技巧进行排序和分页，最终输出所需展示的分页数据。

那么，这里就涉及到至少 2 个问题：
1. 如何高效的从数据库引擎中筛选候选数据集。
对于单表的情况，执行简单查询即可。但是对于分表数据，则需要考虑跨表查询问题，这里就涉及到目标数据表的定位问题。
2. 如何在内存中对候选数据集执行高效的内排序和分页操作。
这里也自然不会简单就把候选数据做一个内存排序，可以借鉴桶排的思想，按照排序字段进行区间划分，然后定位到所需页面数据所位于的 k 个桶，最后仅需排序这 k 个桶中的数据即可。这里涉及到的一些计算和排序的细节往往都有很大的优化空间。

以上。

更正一下上面说的，目前是支持多级分类的，只是可能由于我创建了一些带有特殊字符的分类，导致之后在使用上出现了一些问题，所以分类名称中需要对某些特殊字符进行过滤。

你们家的产品整体感觉算是个大套餐吧，谈一些功能性的问题（因为之前我也有做过一款类似 evernote 的全平台笔记类产品）。就以文档管理这个功能点举例吧，简单试用了一下目前的产品原型似乎并不支持多级目录的分类，文档删除至回收站以后好像也未提供恢复功能。能看得出来，你们在前端上确实花了大功夫，比如富文本编辑器打造的就非常用心。继续回到文档管理这个功能点上来，如果目录层级提供得过于扁平往往是不易于用户日后的使用的，所以一般的笔记类产品都会加入用户自定义标签功能。此外，搜索功能也非常重要，能不能做到真正的又快又准确对于今后的用户体验来说也是至关重要的。暂时先说这些吧。

请移步 MIUI 论坛吐槽让他们看到
http://www.miui.com/forum.php

@Arthur2e5 确实没有找到问题的根源，主要还是对 requests 的 encoding 用法不太了解。感谢指正。

类似的问题还可以面向：
splay tree
avl tree
dancing links
etc.

没有所谓的优雅方案，数据采集永远都是脏活累活，而且属于暗网技术。