在线音乐库项目数据库管理求助：如何避免歌曲重复存储？

Hey there! 你的思路完全踩对了方向——通过管理员统一维护歌曲主库+普通用户关联选歌的模式，刚好能解决重复存储的问题，这也是业界做这类内容平台的标准玩法之一。我来给你拆解下这个方案的关键细节和优化点：

一、核心数据库表结构设计 #

你需要至少3张核心表来实现这个逻辑，彻底避免数据冗余：

1. 歌曲主表（songs） #

这是管理员唯一能操作的表，存储所有不重复的歌曲信息：

CREATE TABLE songs (
    song_id INT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(255) NOT NULL,
    artist VARCHAR(255) NOT NULL,
    album VARCHAR(255),
    duration INT, -- 时长（秒）
    audio_url VARCHAR(255) NOT NULL,
    cover_url VARCHAR(255),
    -- 加唯一约束，防止管理员误添加重复歌曲
    UNIQUE KEY unique_song (title, artist)
);

• 用title+artist的唯一约束，确保同一首歌不会被重复插入（哪怕管理员手滑）；
• 所有歌曲信息只存一次，后续更新（比如换音频链接、封面）只需要修改这张表，所有用户的个人列表都会同步生效。

2. 用户表（users） #

存储用户的账号信息，这个是基础：

CREATE TABLE users (
    user_id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

3. 用户-歌曲关联表（user_songs） #

这是普通用户操作的核心表，用来记录用户的个人歌曲列表：

CREATE TABLE user_songs (
    user_id INT NOT NULL,
    song_id INT NOT NULL,
    added_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    -- 联合主键，确保同一用户不会重复添加同一首歌
    PRIMARY KEY (user_id, song_id),
    FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE,
    FOREIGN KEY (song_id) REFERENCES songs(song_id) ON DELETE CASCADE
);

• 联合主键(user_id, song_id)直接杜绝用户重复添加同一首歌；
• 外键关联确保如果用户删除账号/歌曲被管理员移除，关联记录会自动清理，避免脏数据。

二、权限控制要点 #

• 管理员权限：拥有songs表的INSERT/UPDATE/DELETE权限，以及所有表的查询权限；
• 普通用户权限：仅拥有users表的自身信息修改权限、songs表的查询权限，以及user_songs表的INSERT/DELETE权限（只能操作自己的关联记录）；
• 可以在业务代码层做二次校验，比如普通用户请求添加歌曲时，先检查songs表中是否存在该歌曲ID，再执行插入，防止非法操作。

三、额外优化建议 #

• 给songs表加play_count（播放次数）、favorite_count（收藏次数）字段，用来统计热门歌曲，后续可以做推荐或排序；
• 对热门歌曲做缓存（比如用Redis），减少数据库查询压力，提升用户加载速度；
• 如果需要支持用户自定义歌单，可以再加一张playlists表，然后用playlist_songs关联歌单和歌曲，逻辑和user_songs类似。

这个方案的最大优势就是数据零冗余，所有用户的个人列表都是指向同一首歌曲的关联记录，完全不会出现你担心的热门歌曲重复存储几十次的问题，而且后续维护成本极低。

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