若每种支付一张表，按用户查询所有支付数据就必须关联所有支付表，实质效果就是一张大表，还不如全部支付明细存在一张表，还减少了关联呢，而且要是增加支付方式，要关联更多的表，相关 sql 也都要改，维护也很麻烦。

小米 5s 拍照很好，im378，2000 多，性价比很高，给喜欢旅行拍照的老妈买的，使用反馈非常不错

基本功能没做好，其他的体验卖点都是白搭

这种情况直接在微博上怼，顺带嘲讽一下阿里不管那么多骗子假货不管，偏偏盯上一个卖二手的，at 淘宝、咸鱼、chanel，再 at 几家大众媒体

Word excel web 版不是很方便么，多人协作，版本管理都有

匹配表里用随机函数 select 2 个用户进行匹配，然后从匹配表中删除，这个过程作为一个事务，也就具有排他性了。像楼上所说，考虑扩展功能，需要放在表中，redis 相比之下就无法满足需求了。要说性能，pg 也是很强的。

注册登录不需要模板，因为只有一个。其他实体的增删改查是类似的话，可以用模板方法。将原来实体对象的字段作为元数据存到一个表，包含唯一标识、字段名、长度、数据类型等，实体数据都存到一个业务表，包含实体数据标识、元数据标识和值，根据业务需要，可能要在元数据表或业务数据表增加字段用来条件查询或分组统计，例如表单 id、时间、操作用户等。当需要操作该实体时，可以在各功能的 controller 中读取相应的元数据和业务数据，由 view 对数据在前端控制，例如数字字段只能输入数字，为 HTML 内容提供一个 HTML 编辑器等，提交数据在 controller 做统一安全校验，然后做业务校验。

模板用统一方式的操作实体，可以减少前端工作量，但缺陷有 3 个：1、物理模型和逻辑模型不一致，如果文档不完善，后期运维会有很大问题，所有业务数据是混杂在一个表里的，不知道业务逻辑根本无法筛查出所需数据。2、所有业务数据存在一个表里，在数据量达到千万或存储达到 TB 性能将遇到明显的瓶颈，若 sql 写得不好，索引优化不当，可能几十万数据就会有性能问题，预计 3-5 年到不了性能瓶颈可以忽略，3-5 年使用后一般会有较多改动需求，可以到时再调整架构重构代码。3、同类功能处理不同实体，如果业务相差很多，就得在一个 controller 写大量不同的业务逻辑，这是很糟糕的情况，所以要预先分析，一个模板只操作相似的，少量的不同可以在 controller 处理。要是你各个实体的业务差别都很大，做成模板反而是得不偿失的，不仅没有一致的实体模型，代码可维护性也不高。

模板方式有利有弊，最好评估一下是否有这样的必要。

这个不建议做在一个 view，现有 12 个表，每个 4-5 个 viewmodel，要改成只做在一个 view 里面，那在这个 view 处理的数据可能非常多，后期运维会很麻烦，建议根据业务逻辑适当划分成几个模板，逻辑上会比较清晰，维护也会比较方便

也就是 viewmodel 即模板一个，在 controller 传数据，view 自己负责填充，只做了几个模板就满足了几十个页面的需要

我参与的项目是这样解决的：想用模板方法做，表设计就得按照模板，而不是按业务实体设计表，因为物理实体和逻辑实体不同，对于复杂统计分析的需求还增加了额外的表

从法律角度来说，我觉得网易没有问题。自己没有定期备份，4 月份公告，5 月服务下线也通知了，一个月都没有处理，责任不在网易。从用户体验角度说，网易做的不好，升级服务直接清理数据，显得简单粗暴。

666

1 楼+1 哈哈

一个说好好写代码，避免已知 bug，肯定不会有 sql 注入。一个说总会有写不好代码的时候，所以一定不能避免 sql 注入。就 lz 问题，我认为前者的回答是没有问题的，后者有点吹毛求疵。

工作年限少的都喜欢写精通熟练，我工作年限多了，反而不好意思写了。（害羞脸）

Gps 信号共享，lz 你的发明专利么

国货 ProcessOn Web 在线作图，很方便。

google 不优雅地砍掉一些产品，有些人不放心是可以理解的，不过，Android 是 Google 的战略级产品，在战略级产品上用的开发语言，怎么也会坚持到底的，这都烂尾的话，就属于战略失败了，我觉得 Google 会投入足够多的资源来确保长期发展的

提前 30 天的要求是劳动合同法第 40 条的规定，和裁员有关，和不续约根本没有关系，劳动局根本没有说错，楼上怼错劳动局。另外，不续约补偿，是劳动法第 44、46、47 条规定，补 n 是法定要求，+1 也是和第 40 条的裁员有关，和不续约也是没有关系的。