页面上少做点东西 性能就上来了 每次加载一个页面资源比加载 windows 都多 能快的起来么

假设一个酒店有 1000 间客房，每个月有 90 条记录（假设早中晚可以分别预定），一年的数据量不过：
1000*90*12=1080000 ，也就 100 万条记录，任何一个数据库都可以轻松应付
何况过去的数据不会被查询，实际的数据规模都会远小于这个数
。。。先把需求琢磨明白，按按计算器再考虑设计好吗

@3dwelcome 洗出新风格，洗出新高度，见识了

@cuebyte 不靠自己产品赚钱靠什么？国内互联网公司烧风投的钱烧完关店跑路就很高尚么

Oracle 最强数据库，没有之二

没什么看法，相比于某情怀 mac 版 markdown 编辑器的众筹，这个价对得起这个框架

虽然看不太完全懂你写的什么东西，但是我的理解：
1 、 orm 一般都可以直接绑定 bean 到 sql ，这样如果改字段直接改 bean 的一个注解活着配置就可以了，手写 sql 基本涉及到的每个字段都要写，尤其是各种 join 的时候改哭你
2 、参数过滤，手写的越多 sql 注入的漏洞越多
3 、独立数据库，这个你已经写到了，尤其是 oracle 这种从 limit 和主键开始就跟 mysql 不一样的有 orm 就很重要了

orm 用不用一直都是个争论的焦点，我个人比较偏好于手写，所以有提供最基本 orm 的库，比如 java 的 mybatis ，除了变量过滤、自动转 bean 、还有一些动态 sql 的技巧，所有逻辑全手写

@misaka00251 虾米删的歌太多了，我以前买虾米的，后来发现基本没法听了， acg 下架，钢琴下架，连古风同人都下架了

@shyling 我感觉越大的公司越不会轻易用 node 做主要后端。。。

现在前端不都必须会一门后台语言么

是这样的，如果你的数据是最近抓取的，而且没有经过筛选，那么可能很多都是营销号、抽奖号、僵尸号
这样的数据是没有处理意义的
几十万个微博用户真不多 随便一个抽奖就几万个小号转发

思路就错了 兴趣相似的用户基本就粉了或者互粉了么 肯定先从互粉的人抓起
而且以微博那个超口语化的行文分词也分不出什么来

我现在维护的东西一份代码复制粘贴复制到了大家四五十个文件里吧 重复度 80%以上~

@irisLi 我自己的模块我尽心做好，但是当他拿进度卡你的时候就没法初心了，不上线直接要挨骂的，钱都没了

听老大的 这个锅我们不背 谁给我钱我听谁的

如果是单页面 app 不用 webpack 这种至少你得用 grunt 吧，一个都不用会很痛苦的
当然如果是传统的企业开发一堆一堆的页面，用了 webpack 感觉才会出问题。。。

这番我倒是没看（等完结再说。。），但是对那种跟风刷粉色蓝色梗的表示恶心