@sillydaddy 这样防不住 OCR 啊，用 OCR 识别后重新发就好了

@dynastysea Oracle 并不是性能有多好功能有多先进，而是生态系统绑定，并且培养除了一批拿 Oracle 认证的人，这批人你让他用别的东西是不可能的，还有就是商业数据库很重要的是服务和定制化，从硬件到上次 SQL 设计都可以搞定，客户只要花钱就行了，对于业务相对固定的传统行业决不能接受一个或者多个员工把公司的业务系统把持

@zhaorunze 你的身份证信息就存在 Oracle 里面😊

这种源数据最好就是原始采集不要做任何处理否则随着业务变化或者业务结合，数据容易造成数据载荷丢失、业务僵化，算力扩展困难，直接存到 HDFS 里面无论从经济、生态和灵活性考虑。下游业务抽取数据可以通过 Hadoop 和 kafka 结合，可以并行支撑多个业务线，做一些历史报表也很容易。

@n0rval +1 结果是 cloudFine，如同阿迪王一样。。

@feiandxs docker 需要学习一堆东西，还需要搞 Jenkins 那套，本身这个事干成了收益很低的，不值得额外去学

如果是小公司的话，docker 和 k8s 这些太重了，可以使用 SVN hook 触发构建，python 可以用 wheel 打包成 whl, 然后使用 ssh 执行 pip install package.whl, 然后重启一下 python 就好了

@suisetai 万一老鼠都变异了毒不死怎么办呢。。

结果用异步回调

@wellsc 为什么外企就要重视？

这么干真心不好，自己代码写不好应该自己去解决，这样以后才知道写出 BUG 来就要熬到半夜，以后做事会谨慎一些，从描述上来说，贵公司可能 CI 机制不完善，完善的 CI 机制应该会把很多垃圾代码给干掉，建议加强测试用例和关键流程设计，这样大家都好

看什么类型数据库吧，如果是 NoSQL 和图数据库，基本上都好说。
主要说一下 MySQL 类数据，tag 或者主题类的东西并不稳定可能会经常变动，也有可能是用户自我添加的，后期可能会有画像需求，所以我个人认为最好的办法是新增两张表：

- tag_types：存储用户的 tag，需要有个主键和 tag 唯一标识，tag 名称
- Identity_tags: 里面存储一个主键、userid 、tagID 、还有时间戳，而且需要对用户 ID 和用户信息表做一个外键，防止意外

这个设计虽然会比较浪费存储，但是做画像、推荐都会很方便。虽然 Bitmap 效率很高，但是可读性不太行操作起来也方便

看过京东的文档，不看之前觉得能明白一些，看了之后完全不懂了

保证账号安全，谈单个点事没有意义的，安全是遵循木桶理论。你觉得你的这些措施很安全，假如你服务器被人偷走，你这些措施都没用了

威兔易

鱼塘是人情世故，不是打打杀杀 !-_-