场景如下：
购物网站想要记录每个用户的浏览历史，用户可以查询自己的浏览历史，浏览历史的长度为50。
把所有记录都记在一张表table_total的情况：
每条浏览记录的数据格式为：(user_id, item_id, time) 假设网站的用户人数为： 1,000,000，table_total的最大tupple数应该为：n=50*1,000,000。在user_id上建立索引。
某用户查询时的复杂度：select * from table_total where user_id = curent_user_id 有索引的情况下复杂度为：log(n)。
某用户插入时的复杂度：因为需要知道用户的浏览历史是否大于50，如果大于50了需要把最老的那条记录删除所以也需要先：select * from table_total where user_id = curent_user_id，再判断数据长度是否需要更新。复杂度为：log(n)
每个用户的记录单独存在一个表table_userid的情况：
在用户登录时就记录下用户的对应的userid，每个表中的attributes为：(item_id,time)依照time的值来排序，并且每个表的最大长度都为50。
某用户查询时的复杂度：select * from table_userid。复杂度为：<50
某用户插入时的复杂度：查看表的长度，等于50，删除表中最后一项，插入；小于50，直接插入。复杂度：<2
如果实时同时在线用户数量为10,000，这些用户平均每分钟每人浏览3个items。那么每分钟就有30,000个插入请求产生，这个量应该很大了吧？
问题1：为每个用户单独建立一张表会占用更多的磁盘空间吗？因为一张表时的大小为：3*50*1,000,000 另外索引还要单独占有空间；而每个用户一张表时的大小为：1,000,000*50*2，再加上每张表所需要的额外空间。这么对比一下，如果用户量足够大貌似后者比前者占有的空间要小。
问题2：对比查询和插入的效率都是后者要高一些，而且后者不同的表可以部署在不同的数据库服务器上实现多线程运行，那么这种实现方式到底可不可靠？为什么查询相关问题时这么实现的人都被鄙视啊？
问题3：为每一个用户建立一张表的做法会有这个问题就是表太小了，展现不出数据库的优势，那么干脆就用文件来储存就好了。实际中是不是这么实现的呢？
