这时候你需要Gow - The lightweight alternative to Cygwin，Cygwin如此肥大，何苦难为自己

更正：这里我们应该着重于对“读”优化。 关键的地方出现了口误。。。 ）逃

如果规模很大，先明确不要用join操作。一般情况下“写”比“读”慢40倍左右，而“读”在一般的互联网产品中，比如twitter，读写比是100:1到1000:1。这里的情况假设也是读远高于写（用户经常看到tag但是很少改tag）。这里我们应该着重于对“写”优化。

你的第一种做法，userIdsByTags，是对“求某一tag对应所有用户"很好的读优化，搜索是O(1)。增是O（1），删改是O(k) k是这个tag里面的用户数。相应的tradeoff是userId有很多冗余存在这些lists里面，不方便“求某一用户所有的tag”，搜索是O(m*k)，m是tag的个数，k是tag的平均长度。当然我们可以再冗余一点，加一个tagsByUserIds的表，这样就方便读了。不方便的是写的时候要维护两张表。


你的第二种做法，(_id, userId, tag)的schema，给tag加index，对于“求某一tag对应所有用户"，额外的空间B tree换来的搜索时间复杂度O(logn)，(如果错误请指正)，冗余是两个fields要存很多重复的值。如果同时给userId加index，“求某一用户所有的tag”也是O(logn). 这时候写可能是O(logn + logk)或者O(logn + k)。

所以，
假设时间比空间更宝贵，“读”、“增"要比"改"、"删"多，用第一种。
如果”改“、”删“很频繁，可以考虑用第二种。

TeX学深了是浪费时间，写论文直接套模板就够了。如果仅仅是喜欢显示公式、做笔记，markdown + mathjax 。

ASP.NET WebAPI 用Entity Framework访问数据库，与App通信可以选择json/xml/...格式

纸牌屋第一季视频加上音轨总共听了快十遍了

@kmcool 美国大部分图书馆都弱爆了，开的晚关得早，周末只开半天甚至关门。