mysql 和 es 我都很少用，但是这类使用习惯都是先分析，想清楚历史数据和增量数据以及使用的特征，先在服务器建好库分区分表索引，把数据直接扔上去再根据新结构插进去，这样逻辑清楚，兼顾未来使用，就几千万条数据而已，很快。

@longmeier90 这种都比较理论，你就搜搜传统数据集市设计的内容看看，但通用方法论实际用的时候，还是个经验和玄学的综合体，最后都是取舍平衡，那些通用方法论能实际套用的很少，只能说是借鉴思想。

@smark 深表理解，我家里是我妈干活儿，总有各种要求的统计数据，我妈这个年纪搞不定，就都“外包”给我来帮她做，这些事业单位真是做了一笔好买卖，笃定了不管多麻烦，家里肯定有人给兜底，这么算，她们的薪资水平其实划算的很 /doge

@kevinmissu 绝大部分地区都覆盖了，只要你父母有基本医保就可以，城市的有城市社保，在老家的一般有那种助农之类的，惠民保基本上不设定什么门槛儿，基本上你有户籍大概就都能入，只是每年有一段儿时间开放，今年没赶上就等明年，这个惠民保是唯一一个我强烈建议，尤其是家里有老年人必须要买的；

因为我现在转行做健康了嘛，相关行业的也都会涉及一些，惠民保是保险行业自己的保险规划人员都买的，它们自己的保险（主要是说这类健康险）自己不怎么买，因为它们自己都精算过，能用上的概率实在太低，不划算；

惠民保主要就是为了防止因病返贫，怕老百姓不敢消费设计的，你看每年的报道，保险公司都是接了任务，这个保险根本不为赚钱，120 万的血液肿瘤这类动不动就上线，因为发现真上了线其实得这个病的人也很少，几乎用不到，像南方深圳这类行动力强的城市，一年恨不得调整三次，生怕这个保险的钱花不出去，zz 任务完成的不好；

年轻人反倒是没啥必要买，但是价格也不高，就当是为老年人集资了；

剩下的有很多免费的意外险，其实它们就是用这个来套你的用户资料，然后看看有没有二次销售，你看见的时候，有赠送的，就收下，反正记得它们再打什么电话二次销售之类的，咬住嘴，别轻易下单就行了；

基本上健康方向的，薅免费的意外险，有基本医保，配个惠民保，对于 99%的老百姓，都够用了，我们自己私下开玩笑，常说的一句话是：

“你能看的病，这些保险都包了，看不好的病，要保险也没啥用”

如果你再有更高的追求，想在健康方面以及养老保障方面再深入一步，那这些保险我没什么了解，就不好建议了。

@gongjinchu 行业天花板，你在某个细分领域做到一定程度就会遇到天花板，和你无关，但是和行业有关，人无远虑必有近忧，如果你想未来有更高的天花板，就要在某一个时刻决定是否要赌一把，切换赛道，我是在市场里厮杀一路滚出来的，一个行业从无到有，到开始涌入，惨烈竞争，到最后大家都没利润逐步离开，这个用户生命周期曲线用在绝大部分没有绝对技术或规模护城河的企业上，都适用，这是个选择问题，看你对未来怎么规划了。

1 、之前的数据先不管，现在的数据就别这么搞了，至少现在的数据别真的把数据关系都干掉，这样至少从今天起，后面你就不再发愁了；
2 、历史数据，根据你的业务情况来做分析，比如一般这类东西要用多久，6 个月？ 12 个月？ 24 个月？可以先卡个节点，然后按照创建时间或者使用时间排序，把近期没有再访问的或创建时间久的整体捞出来，也别删，打包压缩先存到别的地方；
3 、28 定律，一般来说，20%的时间把这些折腾了，你觉得乱七八糟的 80%的问题就解决了，至于后面的 20%的麻烦，看你遇到没遇到问题，没遇到就保持这种策略，过个 1 、2 年自然迭代完过了保护期，99%的问题自然就没了，真遇到需要回溯的，至少当前处理之后的你不发愁，在历史里的大不了解压缩拿回来再慢慢找。

单纯这点儿信息资料还是太少了，再多提供一些，比如男性？年龄范围？大概是哪里的人？内蒙古？ 40 来岁？

头一阵子刚泄漏的核酸数据，倒是现在降价了，但自己买也没必要，这阵子估计黑产还在洗，高价值做的差不多才会慢慢放出来供这类需求，有上诉期的话，可以再等等；

数据的事儿，还得找数据专业的人问 /doge

这个问题，加钱就能解决。

我做了很多，结果都失败了；

我原来是做大数据团队的，在系统和应用研发的后端，但是业务原因，我们的诸多业务都是依赖数据的，而且规模也大，对这个我是真的深恶痛绝；

以前重构系统，我们做过词汇提炼，设计过库表字段的词组结构和命名语法，在内部技术站发布，在重新研发新系统的时候也进驻，然后为了确保统一，都主动在实施前主动要求增加流程，把同一语义作为一个审核流程环节加进去，但是又怕研发兄弟姐妹们嫌弃我事儿多，所以还主动把事儿接过来，拿到新数据结构，让我们团队给统一梳理做完命名后再发回给研发团队…… 各种事儿，前前后后做了不知道多少；

最后依然是鸡飞狗跳，这个东西吧，就是得从建团队的时候，研发老大得把这个东西当成一种文化来建设，不然等到团队规模大了，系统应用多了，完全就是无组织无纪律；

我们和系统 /应用研发团队的矛盾很多都基于此，系统 /应用研发团队主要看业务逻辑是不是通，其他的不管，但是就没考虑过做大之后，我们在后端要应付的麻烦有多少，反正到最后我放弃了，跟团队的兄弟姐妹说，咱们自己的数据系统命名就叫垃圾回收站，寓意不管系统应用那边怎么折腾怎么用，反正数据丢回来我们在这里重新分类清理当成再生资源，都处理好再返回给各个系统；

回首往事，提起这些都是泪。

就像搞个小系统，问自己研发，一算人工时成本 1 万，一问外面外包 3000 ，那技术一定会站出来竭力反对，比如代码没保障，搞完了一定会要求加钱 blablabla ，不然自己存在的意义是什么，尤其是对自己技术能力和业务知识都有限的人来说，大系统搞不了，小功能现在又用不着，人家业务自己搭着搭着就搞定了；

我 N 年前就跟数据分析师团队说过这句话，无论接受与否，相关的应用技术一定会越来越普及，基础人员的应用能力也会随着新人的成长而逐步普及化，除去极端细分领域，现在哪里还听得到需要打字员了；

做小的基础应用，零代码平台确实对普通业务人员极其友好，自己本身就懂业务，拼拼搭搭效率自然比中间传来传去的效率高多了。

业务端不敢苟同，但是在此类技术领域，相比这些资源企业，百度还是更靠谱点儿的。

@anyele 乱讲，你加一下就知道是不是真的了，反馈特别及时 /doge

实战最靠谱儿，去网上下载点儿泄露数据源，比如说某选美比赛数据集；

此时你有想法，你想知道年龄在 20 ～ 26 岁的，身高 170 以下的，在自己本地的姑娘，有微信联系方式的，并且按照胸围降序排列……

有了核心需求，各种复杂查询关联分析都如鱼得水，比用什么学习网站快多了。

@buyan3303 这个我倒还真能给你简单科普下，如果是在这种标准框架下来谈，其实也不用考虑什么等级，按照传统来看就是两种，心理医生和心理咨询师，心理医生可以同时为咨询师，相比咨询师主要是多了个处方权，咨询师是一类泛指，但是没有行医资格的就是没处方权；

不过如果你还没润的话，在国内，也都是泛指，因为刚起步的时候咨询师被玩儿烂了，所以现在其实是没有“咨询师”的，因为原来行业认定的被“取缔”了，现在所谓的认证，其实都是商业游戏，就是商业内系统循环而已，都是“行业自律”；

当然国际上新（也不能说新，也很多年了）的也有在描述叫做心理教练，它是横跨在医疗方向和自我成长之间的一个新物种，心理辅导（疏导比较聚焦于解决现有的接近心理或躯体障碍层面的问题）是解决括号里这些的，但很多人并不满足于这个阶段，或者说还想完善自我，在生活或职业生涯里的，就是在原有合同的分类里多了一种教练合同，你可以把它当成体育运动教练那种；

你说的变现其实是一个主体，但其实只是心理行业中变现的一个维度，心理行业，尤其是以老美体系框架来运转的，其实是个大内循环，很大一部分体量的收益其实不是来自于来访者（专业名词，就是指去寻求心理辅导帮助的“患者”），而是来自于想从事心理咨询行业的人，比如你从事这行，我前面提了，“行业自律”，你要参加培训的，要接受督导，不然你不能“升级”，这些都是外面看不到的收益来源；

所以我早就算过这个数儿，我是在北京嘛，做数据的人用数据说话，我用相关的收入数据给大家做过测算，即便是以北京的收入水平为例，中位数的水准都不足以支撑心理咨询的服务，出去北京就更别提了，这个市场根本不是那么大，就像前几年鼓吹中国咖啡市场多大盘子一样，核心在于国民收入水平是不足以满足这个庞大市场的，这也是为啥我在自助指南里要介绍那么多去医院通常价格的原因，因为你可能接触的少，不知道真正有这类问题的民间疾苦，尤其是抑郁类群体，大部分那 1 个月 200 块药钱都不是那么容易拿出来的；

如果说一定要做 app ，也不是不行，一般做 app 的盈利方法其实是卖课，因为只有卖课的利润才算高，其他诸如咨询这类，如果不做刚我前面说的行业内“培训”、“督导”，只是做咨询，你会发现所有的利润都被咨询师群体和配合运营的人吃光了，技术研发费用都是赔钱的，所以只有做在线课程降低咨询师成本，才可能有收益；

当然再具体的细节上，就很多了，我在前面谈经济和那个创意的时候里面讲过，现在年代不同了，每个行业内都有行业自己很精细的操作和运营，光是个灵机一动的点子基本上都不会有机会的，举个小例子，比如说乳腺癌群体，其实这类群体有很大的焦虑问题，当然绝大部分都是收入本身就非常有限的，只有金字塔尖儿那一点儿是有消费能力的，你再细分术前术中术后，都有无数细分的场景和细节，举个绝大部分人能理解的场景，术后想做修复术，这个就确实是你能直接导流的，而且是这类群体切身需要的，她就是因为这种肢体缺失而自卑焦虑等等……

这种具体的行业细分或技术细节问题，能说的就太多了～

首先，一定不能这样无休止为了“方便”在无数个表上加字段；

看样子系统也不太可能短期内重构；

但这样无休止加下去早晚会出问题，所以为了稳定，短期内无法做大调整的时候，我们以往的经验是先做分层；

把你现在手里的表都拿出来，先做一次分析，哪些是业务核心表，哪些是报表数据等等，把表类型先分层，然后建层，就像建数据分析集市，哪些是事实哪些是维度哪些是业务层哪些是汇聚层等等，保持业务系统不变，但是把逻辑通过数据处理层解决，这样就可以把 1 对无限多的问题转换成局部问题。

@golangLover 关键词 [信贷系统+开源] ，随便找几个，在测试服务器上部署下，看看后台表结构借鉴一下就行了。

@buyan3303 打工给资本家吸血多不划算，这要是给自己预热呢，把流量都吃到自己名下，那利润比一下就上去了，格局，格局，格局，做员工没出路的。

tinder

习惯就好了，绝大部分人都会在某些时段出现这种情况，引起的原因多种多样，只要没有什么其他特别的生理不适，顺其自然。