关系型数据库并不过时，它们强在把数据可靠性变成默认能力。ACID 事务、外键、唯一约束、非空约束和检查约束，看起来不如高吞吐基准耀眼，却替应用承担了最难处理的工作：失败、并发、崩溃和边界情况下的数据一致性。许多 NoSQL 系统之所以显得更快、更容易横向扩展，是因为它们放弃或弱化了部分保证，例如即时一致性、复杂查询、跨表关系和严格模式。这不是单纯的技术进步，而是复杂度转移：数据库少管的事情，应用代码、后台任务和人工修复就要多管。对海量写入、简单键值访问、特殊分片需求或最终一致性可接受的场景，非关系数据库很合适；但在大多数业务系统里，干净、结构化、可长期维护的数据更重要。应用会重写，数据会留下。选择数据库时真正要问的不是谁更现代，而是谁承担了哪些代价。
CTE 可以直接充当一次性查找表，用来把数据库里的代码值转换成更适合展示的文本。面对国家代码、状态码、类型码这类字段，常见做法是在查询里写 CASE 表达式，但分支一多就会让主查询变得臃肿；同样的映射如果在多个地方使用，还得反复复制，维护时容易漏改。更清爽的写法是在查询开头用 CTE 构造一张小表，把 code 和 label 一行行列出来，再在主查询中 JOIN 或多次引用它。这样映射规则集中、可读性更好，也更接近真实维表的思路。对于 SQLite 和 PostgreSQL 这类支持 CTE 的数据库，这是一种轻量、无需建表、适合报表和临时分析的技巧。它不替代正式的数据建模，但能让一次性查询少些噪音。
面对数据库容量或性能瓶颈，先充分挖掘现有系统，再引入分片等会显著增加复杂度的架构。文章以 Postgres 优化为例，说明团队可通过遥测定位重查询、优化或消除低效代码、调整负载和补充系统能力，延后数月甚至数年的扩容压力。这个过程不仅节省工程时间，也会积累跨团队的系统知识；只有当业务需求确实超过现有技术边界时，才值得承担架构跃迁的成本。
DemoChen's Clip