瞎 YY 些啥

@K1W1 只有一个字段的话，数据库优化器会判断候选结果集是否超出了全部结果的 5%（估计），如果超过，那么就全表扫描。所以像> < in 这种操作，走不走索引要看本身可能的结果数量。

一般是建立 联合索引比如 index(a, b) 然后查询的时候 where a = key1 and b > ... 。这个时候 b 的不等于操作是基于 a 字段索引下的扫描。B+树的构造决定了索引怎么走。另外，现在只需要写 SQL 就可以直出 web 了：enhancer.io

能被替代的都是重复劳作，有创造力的工作是永远无法被替代的。

@WinterWu 那你还不如用 https://enhancer.io

@jokerjoker 如果是直接用 jquery 的列表组件，拿到 JSON 数据直接渲染呢？不过你说的那种特殊定制化的无法组件化的列表另说。

@shew2356 #55 考虑运维时的成本才是实战真知！老板思维会让你走得更远：）

@jjx glup build 做个压缩还是会用的，不然文件的组织会是一个灾难。webpack 感觉上配置有点复杂。。。

@fuermosi777 我们业务的一个页面会有不少列表，表单，表单之内各种输入域联动，多重校验。不知道算不算复杂。 希望能给出复杂的前端用例啊

@SuperMild 基本代码约定还是有的，的确如果不做编码规范最后代码的组织是一团豆腐渣，很难维护。只不过这些约定一定需要引入 React 或者 Vue 来解决吗？ Vue 确实相对简单容易上手一点。

程序写到最后都是一样的，即做一份翻译工作

至少传统企业级应用开发，SQL 的地位是无法替代的，现在只需要写 SQL 就可以直出 WEB 系统了：enhancer.io