共 3 篇相关文章
这篇讲的是电信与互联网系统中常用的“三户模型”。作者从eTOM框架出发，梳理了客户（Customer）、用户（User）和账户（Account）这三个核心实体如何以“以客户为中心”的理念进行构建与区分。 关键在于厘清三者的边界：客户体现社会域信息，是自然人或法人的实体身份，即使不使用业务也客观存在；用户体现业务域信息，是客户登录和使用产品的账号实例；账户则体现资金域信息，负责交易记账。它们之间是归属与映射关系，但各自独立。 文章以电信业务为例具体说明：一个客户（张三）可以开通多个用户（如手机和宽带），这些用户又由一个或多个账户来付费，形成了灵活的映射。在互联网实践中，客户归并（如通过身份证号识别同一人）、用户的生命周期管理（从注册到销户的复杂流程）、以及账户的多样化建模（支付、结算、风控等需求），都围绕这套模型展开，以支撑起以客户为中心的业务管理与数据统计。
这篇从游戏DBA的实战视角出发，聚焦于数据库范式这个基础却常被忽视的核心知识。作者以面试经验为例，指出许多半路出家的DBA对范式理解不深，并特别提到了一个常见细节：面试官常问`int(n)`与`varchar(n)`中的`n`究竟代表什么。这背后直指对数据类型与存储机制的基本功考察。 文章由此展开，说明了范式不仅仅是理论，而是直接关系到数据一致性、冗余控制和查询效率的工程实践。对于游戏场景，合理的范式设计能有效应对高并发下的数据变更与统计需求。作者通过对比范式掌握程度不同的DBA在问题分析上的差异，强调了扎实的理论基础对于长期维护数据库健康的重要性。 整篇内容扎实，没有空谈理论，而是将范式知识与游戏业务的具体语境和面试中的真实考察点紧密结合，让读者看到基础概念在实践中的重量。
这篇讲的是如何用SQL解决一个实际的数据分析需求：从登录表中筛选出在指定时间段内连续7天都有登录的用户。作者从朋友遇到的一个具体问题出发，表结构包含用户ID和登录时间戳两个核心字段，看似简单，但“连续7天”这个条件对SQL查询能力提出了直接挑战。 文章拆解了这个查询背后的逻辑难点——如何用集合操作去表达“连续”这个时序概念。读者可以跟随作者的思路，理解如何利用日期处理、窗口函数或自连接等SQL技巧，将连续天数的判断转化为可执行的查询语句。这种对常见业务指标（如用户活跃留存）的底层查询实现，往往比直接调用现成函数更考验对数据库原理的掌握。 这类问题在用户行为分析、运营报告中极为常见。文章的价值在于，它不仅仅给出了一个答案，更展示了解决此类时序连续性问题的通用分析框架，下次遇到类似“连续N次”、“连续N个周期”的需求时，便能举一反三。
