多用户多词典的数据库表设计咨询及现有方案优化建议

原结构的不合理之处 #

• 数据冗余严重：同一个词典下的所有单词都会重复存储用户ID、词典名称，不仅浪费存储空间，要是改个词典名字，还得批量更新一堆记录，很容易出问题。
• 不符合数据库设计范式：词典和单词是一对多的关系，把它们塞在同一张表里，逻辑上混乱，也不满足第二范式——用户ID、词典名称只依赖词典ID，和单词本身的属性无关。
• 扩展性差：以后要是想给单词加个词性、例句，或者给词典加个创建时间、描述，这张表会变得越来越臃肿，维护起来特别麻烦。

优化后的表结构设计 #

我们可以把表拆成两张，分别负责词典信息和单词信息，通过外键关联，清晰又高效。

1. 词典表（Dictionary）

用来存词典的基础信息，每个词典对应一条记录：

create table Dictionary(
  id int primary key auto_increment, -- 词典唯一标识ID
  userId int not null, -- 该词典所属的用户ID
  pseudonym varchar(100) not null, -- 词典的自定义名称（别名）
  create_time datetime default current_timestamp -- 可选字段：词典创建时间
  -- 还能按需加其他字段，比如词典描述、是否公开等
);

2. 单词表（DictionaryWord）

用来存每个词典下的单词，通过dictionary_id绑定到对应的词典：

create table DictionaryWord(
  id int primary key auto_increment, -- 单词记录的唯一ID
  dictionary_id int not null, -- 关联的词典ID
  original_word varchar(50) not null, -- 生词原文
  transcription varchar(100), -- 音标（允许为空，部分单词可能没有音标）
  translated_word text not null, -- 译文内容
  add_time datetime default current_timestamp -- 可选字段：单词添加时间
  -- 可按需扩展字段，比如词性、例句、记忆标签等
  foreign key (dictionary_id) references Dictionary(id) on delete cascade
);

优化方案的优势 #

• 消除冗余：词典的基础信息只存一次，修改词典名称只需更新一条记录，省心又省空间。
• 结构清晰：每张表职责单一，符合数据库设计的规范，逻辑上一目了然。
• 扩展性强：后续给单词或词典加新属性，直接在对应表加字段就行，不会影响原有数据结构。
• 数据更一致：外键约束能保证单词不会关联到不存在的词典，删除词典时还能自动删掉其下所有单词（on delete cascade的作用），避免出现孤儿数据。

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