MySQL参考文献数据库中页码的最优处理方案探讨

你的page_range表方案是合理的，完全不算冗余，反而很贴合你遇到的实际需求——支持多段跳转页码和非纯数字页码格式。

为什么单独建表不冗余？ #

一个text实体可能对应多个不连续的页码范围（比如你提到的130–35、206–7这种跨页的情况），这是典型的一对多关系。如果硬把多个页码范围塞进text表的字段里（比如加first_page1、last_page1、first_page2这类字段），不仅扩展性极差（后续遇到3段、4段页码就没法处理），还会导致数据结构混乱。单独建page_range表是符合关系型数据库范式的设计，能灵活处理任意数量的页码范围，同时通过text_id关联，数据逻辑清晰。

现有方案的优化点 #

你的page_range表结构可以再细化一下：

• first_page和last_page要指定具体长度，比如VARCHAR(20)足够覆盖绝大多数英文页码格式（包括字母数字混合的情况，比如"C9"、"WC13"）；
• range_ordinal字段很关键，它能保证多个页码范围的顺序（比如先展示130–35，再展示206–7），查询时可以通过这个字段排序，避免页码顺序错乱。

其他可选方案 #

如果你的系统对页码范围的查询、筛选需求不多，只是做存储和展示，也可以考虑以下轻量方案：

• JSON字段存储：在text表中新增page_ranges JSON字段，把所有页码范围以JSON数组形式存储，比如：

  [{"first":"130","last":"35","ordinal":1},{"first":"206","last":"7","ordinal":2}]
  

  优点是不用额外建表，实现简单；缺点是如果需要按页码范围做筛选、排序，性能会比单独的page_range表差，而且数据完整性约束（比如确保每个范围都有first和last）更难通过数据库层面实现。

总结 #

如果你的系统需要频繁处理页码范围的查询、排序，或者需要严格保证数据的规范性和完整性，那你的page_range表方案就是最优选择，完全不存在冗余问题。如果只是基础的存储展示，JSON字段方案更轻量，但灵活性和规范性不如单独建表。

内容的提问来源于stack exchange，提问作者practik