yinwang1.substack.com/p/database

这是一条过度概括的技术性断言，但它与主流 RDBMS 的实际能力不符。

• 可变长度数据并不是 RDBMS 的例外，而是常见能力。 PostgreSQL 9.1 文档明确列出 character varying / varchar 为“variable-length with limit”，text 为“variable unlimited length”，并说明未指定长度的 character varying 可接受“strings of any size”。这直接反驳了“表行宽度固定，无法存储可变长度数据”的说法。
• 数组也不是 RDBMS 普遍“无法存储”的对象。 PostgreSQL 9.1 文档明确写道：表的列可以被定义为“variable-length multidimensional arrays”。也就是说，至少在这类成熟 RDBMS 中，数组列是原生支持的，而不是必须一律“旋转 90 度”拆成另一张表。
• MySQL/InnoDB 也支持变长列。 官方文档说明，VARCHAR、VARBINARY、BLOB、TEXT 等长变字段会以变长方式存储；在 ROW_FORMAT=DYNAMIC 时，长变长列甚至可以整列 off-page 存放。这再次说明把“RDBMS 行宽固定”当作通性是不准确的。

更准确的说法应该是：某些关系设计会把可重复/多值属性拆到子表中，但这不是因为 RDBMS 普遍“不能存可变长度数据或数组”，而是因为范式设计、查询需求、约束表达、索引与可维护性等原因。

这句话把“数据库如何做 I/O / 缓存”的实现方式一概而论了，但官方文档显示事实并非如此。

• PostgreSQL：官方文档写明，dynamic_shared_memory_type 的 mmap 选项“is not the default on any platform”，而且“is generally discouraged”。也就是说，PostgreSQL 并不是“直到今天仍依赖 mmap 存储数据”的例子；相反，mmap 连默认项都不是。
• SQLite：SQLite 关于 memory-mapped I/O 的官方文档说明，mmap 是从 2013-05-20 的 3.7.17 开始才加入的可选能力，而且“disabled by default”。这与“数据库仍然依赖 mmap”正相反：至少在 SQLite 中，mmap 不是长期既有的必需机制，也不是默认行为。
• MySQL / InnoDB：官方文档说明 InnoDB 的核心性能结构是自己的 buffer pool，即在主内存中缓存表和索引数据；文档还单独说明 myisam_use_mmap 可以设置为 1 才为 MyISAM 启用 memory-mapping，说明 mmap 是一个可选开关，而不是整个数据库系统普遍“依赖”的基本机制。

因此，这里的问题不是“某些数据库从不使用 mmap”——有些系统、某些引擎、某些场景确实会提供 mmap 选项——而是原文把这种可选、非默认、因产品而异的实现细节，说成了数据库整体“直到今天仍然依赖”的共性。这一点与官方文档不符。

这句把 SQL 的标准化时间 和 SQL 的起源时间 混在了一起。

• IBM 官方资料写明：SQL 是 1970 年代由 IBM 的 Donald Chamberlin 和 Raymond Boyce 开发并推出的，随后在 1979 年开始商业可用；1986 年才由 ANSI 标准化，1987 年再由 ISO 标准化。
• Open Group 的 SQL 历史资料也明确写道：SQL 是 IBM 在 1970 年代末随 System R 原型推进的语言，而 1986 年是“the first de jure SQL standard”。

所以，如果作者想说的是“Prolog 和 Datalog 早于 SQL 的标准化”，那 1986 年这个日期对应的是 ANSI 标准，而不是 SQL 语言本身的出现时间；如果说的是“比 SQL 早出现”，那把 SQL 写成 1986 年就不对了。