博主介绍：✌ 专注于VUE,小程序，安卓，Java,python,物联网专业，有18年开发经验，长年从事毕业指导，项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题，我会尽力帮助你。

一、研究目的

在数字音乐时代，用户对个性化音乐内容的需求日益增长，传统基于手工标签或静态推荐的系统已难以满足多样化、动态变化的听歌习惯。随着海量音乐资源的涌现，如何从海量数据中快速、精准地为用户挖掘潜在喜好，成为音乐信息检索与推荐研究的重要课题。与此同时，用户对推荐结果的实时性与可解释性的要求也在不断提升，这对推荐系统的技术架构与算法性能提出了更高标准。

现有音乐推荐系统普遍面临数据稀疏、冷启动以及算法更新滞后的问题。尤其在多平台、多终端场景下，用户行为信息分散存储，导致协同过滤等基于用户-物品交互矩阵的方法难以获得足够的训练样本。再者，传统推荐框架往往采用单体应用模式，难以支持高并发请求与快速迭代算法更新。为此，本研究旨在构建一个基于SpringBoot的微服务化音乐推荐平台，以解决上述瓶颈。

本平台将采用SpringBoot作为核心框架，利用其成熟的依赖注入、自动配置与模块化特性，实现业务逻辑与基础设施的解耦。数据层将通过分布式缓存与消息队列实现用户行为实时采集，并使用Spark等大数据工具进行离线特征工程。推荐算法层将集成协同过滤、内容分析与深度学习模型，并通过A/B测试机制持续评估模型效果。系统架构设计将支持水平扩展与灰度发布，以满足高并发访问与快速迭代的需求。

通过上述技术路线，本研究期望实现音乐推荐准确率提升10%~15%，系统响应时间降低至百毫秒级别，并提供可视化的推荐解释接口，增强用户信任感。平台的模块化设计将为后续功能扩展与跨领域应用提供可复制、可维护的技术基础，从而推动音乐推荐技术在实际商业场景中的落地与创新。

二、研究意义

在数字音乐产业快速发展的背景下，用户对个性化内容的需求呈指数增长，传统基于静态标签或单一算法的推荐系统已难以满足多维度、动态变化的听歌习惯。针对这一痛点，本研究通过构建基于SpringBoot的微服务化音乐推荐平台，旨在为学术界与产业界提供一种可扩展、高效且易于维护的技术范式，从而提升音乐内容发现的精准度与用户体验。

从理论层面来看，该平台通过融合协同过滤、内容分析与深度学习等多模态算法，形成了一个多层次、多特征融合的推荐框架，可有效缓解传统协同过滤所面临的数据稀疏与冷启动问题。与此同时，利用SpringBoot的模块化设计与自动配置特性，使得模型迭代与算法实验能够在不影响整体系统稳定性的前提下快速完成，从而为推荐算法研究提供了可复制、可验证的实验环境。

在实践层面，本平台实现了高并发请求处理与实时数据流的无缝对接，能够满足数百万级用户同时在线的业务需求。通过引入分布式缓存与消息队列，系统能够在毫秒级别完成用户行为采集与特征更新，进一步缩短推荐结果的时延，提高用户满意度。与此同时，可视化的推荐解释接口不仅提升了系统透明度，也为音乐内容运营提供了数据驱动的决策支持。

从产业价值角度而言，该平台可直接嵌入现有音乐服务商的技术栈，降低系统集成成本，并通过微服务架构实现业务模块的独立升级与灰度发布，显著提升业务弹性与持续交付能力。对学术界而言，本研究首次将SpringBoot微服务框架与大规模音乐推荐系统深度结合，为后续跨域技术融合提供了可借鉴的实践案例，并为相关算法在真实场景中的验证与优化奠定了基础。

综上所述，该研究不仅在理论上丰富了多模态推荐算法的研究视角，也在实践中提供了一套可落地、可扩展的技术解决方案，具有重要的学术价值与产业意义。

三、国内外研究现状

国内外在音乐推荐领域的研究已形成多条主线，主要包括协同过滤与矩阵分解、内容分析与深度学习、图神经网络与社交网络融合以及可解释性与强化学习等方向。早期研究普遍采用基于用户-物品交互矩阵的协同过滤方法，随后引入奇异值分解与非负矩阵分解技术以缓解数据稀疏问题，取得了较为显著的推荐精度提升。然而，这类方法对冷启动场景表现不足，且难以捕捉音乐内容的多维特征。为此，学术界开始关注内容分析技术，通过提取音频信号的节奏、调式、情感等低层特征以及歌词语义信息，将音乐项目映射到高维向量空间，从而实现基于内容的推荐。近年来，深度学习模型如卷积神经网络与循环神经网络被广泛用于音频特征提取，进一步提升了对音乐情感与风格的捕捉能力。国内顶尖高校在此基础上开展了多模态融合研究，将音频、歌词、用户行为与社交关系等多源信息进行联合建模，形成了更为丰富的用户画像与项目表示。

与此同时，图神经网络技术被引入音乐推荐，以构建用户与音乐之间的异构图结构，利用节点传播机制捕捉潜在关联。国内研究团队在此方向提出了基于注意力机制的图卷积模型，并通过实验验证其在大规模数据集上的优越性。国外学术界亦开展了类似工作，探索利用知识图谱与音乐元数据进行语义增强，从而提升冷启动和多样性表现。

可解释性与强化学习是近几年备受关注的热点。可解释推荐系统通过生成对用户行为的因果分析或特征重要性评估，提升用户对推荐结果的信任度；强化学习方法则将音乐播放行为视为环境状态，利用奖励信号动态调整推荐策略，实现长期收益最大化。国内外多篇论文在这两方面取得了突破，例如基于注意力机制的可解释模型与基于马尔可夫决策过程的强化学习框架。

在技术实现层面，云原生与微服务架构被广泛讨论，以提升系统的弹性与可维护性。国内研究者提出了基于容器化与弹性伸缩的推荐服务部署方案，国外研究则侧重于多节点分布式训练与在线学习框架。总体而言，当前研究正从单一算法向多模态、多源融合、可解释性与在线学习等方向演进，以满足海量用户对个性化、高质量音乐体验的需求。

四、预期达到目标及解决的关键问题

本研究的总体目标是构建一套基于SpringBoot技术栈的微服务化音乐推荐平台，既满足高并发访问下的低延迟响应，又兼顾多模态数据融合与模型可解释性，从而显著提升用户对音乐内容的发现效率与满意度。该平台应在保持系统可维护性与可扩展性的前提下，实现算法迭代与业务功能更新的无缝衔接，支持在线学习与离线批处理的混合工作流。

为实现上述目标，预期完成以下关键任务：首先，构建统一的数据采集与特征工程管道，将用户行为日志、音频信号、歌词文本以及社交关系等多源信息进行标准化处理，并通过分布式缓存与消息队列实现实时数据流的低延迟传输；其次，设计并实现多模型融合框架，兼容协同过滤、内容分析与深度学习模型，并通过模型集成技术提升推荐准确率；再次，开发可解释性模块，为每条推荐结果生成可视化的因果说明或特征重要性评估，以增强用户对系统的信任感；最后，构建弹性伸缩的微服务架构，支持灰度发布与滚动升级，并通过监控与日志聚合实现系统运行状态的实时可视化。

在技术实现过程中将面临若干关键问题。数据稀疏与冷启动是首要挑战，需要通过多模态特征补全与知识图谱推理来缓解；算法融合与模型选择需兼顾准确性、计算成本与可解释性，避免模型过拟合或解释性缺失；实时推理要求模型压缩与加速技术的结合，以满足毫秒级响应需求；系统可扩展性和容错能力需通过分布式部署与服务治理实现，防止单点故障导致业务中断；持续学习与模型更新需要在保证业务稳定性的前提下实现在线学习，避免模型漂移导致推荐质量下降；此外，用户隐私保护与数据安全也必须在数据采集、存储与处理环节得到充分保障，以符合相关法规与伦理要求。

为验证平台的有效性，将采用多维度评估指标，包括精准率、召回率、覆盖率、多样性、实时性以及系统吞吐量和资源利用率等。通过对比实验与线上A/B测试，预期实现推荐准确率提升10%~15%，系统响应时间降低至百毫秒级别，并在可解释性方面获得用户满意度显著提升。

五、研究内容

本研究围绕构建基于SpringBoot技术栈的微服务化音乐推荐平台展开，整体研究内容可划分为系统架构设计、数据采集与特征工程、算法研发与模型训练、在线推理与服务治理以及系统评估与实验验证等五大模块。

首先，在系统架构设计层面，本平台采用SpringBoot作为核心框架，利用其自动配置与依赖注入机制实现业务逻辑的解耦。整个系统被划分为用户服务、音乐服务、推荐服务、数据处理服务以及监控与日志聚合四大微服务，每个微服务通过RESTful API或gRPC进行通信，并在Kubernetes集群中部署以实现弹性伸缩。API网关负责统一鉴权与流量控制，缓存层使用Redis实现热点数据的快速访问，消息队列Kafka承担用户行为日志与模型推理结果的异步传输。

其次，在数据采集与特征工程层面，系统将从前端应用、移动端以及第三方音乐平台收集用户点击、播放时长、收藏与分享等行为日志，并将其写入Kafka主题。后端通过Spark Streaming对实时日志进行解析，提取时间戳、用户ID、歌曲ID及操作类型等字段，同时调用音频处理库对原始音频文件进行MFCC、节奏与情感特征提取，利用自然语言处理技术对歌词文本进行分词与情感分析。所有特征被统一映射到向量空间，并存储于HDFS或对象存储中，为离线模型训练提供高质量输入。

在算法研发与模型训练层面，平台将实现多模态融合推荐框架，兼容基于矩阵分解的协同过滤、基于音频与歌词特征的内容分析以及基于Transformer的深度学习模型。协同过滤模块采用ALS或SVD++算法，在用户-歌曲交互矩阵上进行分解，得到低维嵌入向量；内容分析模块利用CNN提取音频谱图特征，并通过多头注意力机制聚合歌词语义信息；深度学习模块则基于BERT或Wav2Vec对文本与音频进行联合编码，进一步提升对音乐情感与风格的捕捉能力。上述三种模型的输出向量将通过加权融合或Stacking技术进行组合，以获得最终推荐得分。模型训练采用离线批处理方式，使用Spark MLlib或TensorFlow在GPU集群上完成，训练结果通过Model Registry进行版本管理。

在线推理与服务治理层面，推荐服务将从Model Registry加载最新模型权重，并在接收到用户请求时通过缓存层快速获取用户嵌入向量与歌曲特征向量，使用GPU加速的推理引擎（如ONNX Runtime）计算得分。为满足低延迟需求，系统采用异步推理与结果预取机制，并通过Circuit Breaker与重试策略保证服务可用性。推荐结果将返回给前端，同时写入Kafka主题供离线日志分析与模型更新使用。监控层面，平台集成Prometheus与Grafana进行指标采集与可视化，ELK堆栈用于日志聚合与异常分析。

最后，在系统评估与实验验证层面，本研究将采用离线评估指标如Hit Ratio、NDCG、Recall以及多样性指标，并在真实用户群体中开展A/B测试，比较基于本平台的推荐效果与传统协同过滤或内容推荐方案的差异。实验结果将从准确率、覆盖率、多样性与系统吞吐量等维度进行综合评估，并通过统计显著性检验验证改进措施的有效性。

综上所述，本研究通过系统化的架构设计、完善的数据管道、创新的多模态推荐算法以及高效的在线推理与治理机制，旨在为音乐平台提供一套可扩展、高性能且易于维护的推荐解决方案，并通过严格实验验证其在实际业务场景中的优越性。

六、需求分析

用户需求方面，首先需要满足对个性化音乐内容的高度期待，用户期望系统能够根据其历史收听行为、收藏偏好与情感倾向，精准推送符合其审美与心情的歌曲；其次，由于音乐消费场景多样化，用户期望在手机、平板、电脑等多终端之间实现无缝切换，且在不同设备上均能获得一致的推荐体验；再次，鉴于音乐内容的丰富性与多样性，用户对推荐结果的多样性与新颖度有显著需求，希望系统能够兼顾热门曲目与冷门精品，从而避免“同质化”体验；再者，随着数据隐私意识提升，用户期望平台能够透明展示其数据使用方式，并提供可控的隐私设置，以保障个人信息安全；最后，用户对推荐结果的可解释性也持关注态度，他们希望能够了解系统为何将某首歌曲推送给自己，从而提升对平台的信任与满意度。

功能需求方面，系统首先需具备高效的数据采集与日志处理模块，以实时捕获用户点击、播放时长、收藏、分享等行为，并将其写入分布式消息队列；其次，需要构建多模态特征工程管道，对音频信号进行MFCC、节奏与情感特征提取，对歌词文本进行分词与情感分析，并将所有特征统一映射到向量空间；再次，平台必须实现离线模型训练工作流，支持协同过滤、内容分析与深度学习模型的并行训练，并通过模型注册中心管理不同版本；随后，在线推理服务需提供低延迟的RESTful或gRPC接口，利用GPU加速推理引擎完成用户嵌入向量与歌曲特征向量的相似度计算，并返回推荐列表；再者，为满足可解释性需求，系统应集成特征重要性评估模块，能够在推荐结果中附带关键特征说明或可视化图表；此外，平台需提供用户画像管理功能，包括兴趣标签、情感倾向与播放习惯的动态更新；最后，为保障系统稳定与可维护性，必须配备缓存层、流量控制、熔断器、监控告警与日志聚合等基础设施，以实现弹性伸缩与高可用。

七、可行性分析

经济可行性方面，本平台的核心技术采用开源框架SpringBoot、Kafka、Spark以及TensorFlow等，能够显著降低软件授权与维护成本。系统部署在云原生环境中，可通过按需计费实现资源弹性伸缩，避免因流量波动导致的资源浪费；同时，微服务化架构使得功能模块可独立升级与扩容，减少整体系统停机时间，从而提升运营效率。基于多模态特征的推荐模型在离线训练阶段需要GPU集群，但通过使用共享云GPU实例或预留实例，可在保持性能的同时降低硬件投入；此外，平台的可解释性模块为音乐服务商提供了差异化竞争优势，可通过增值服务实现收益提升。综上所述，平台在初期投入与长期运营成本之间实现了良好平衡，具备可观的经济回报潜力。

社会可行性方面，随着数字音乐消费的普及与多元化，用户对个性化、高质量音乐体验的需求日益增长。平台通过精准推荐与多样化内容分发，有助于提升用户满意度与黏性，从而推动音乐产业链条的发展。与此同时，平台在数据采集与使用过程中将严格遵守《个人信息保护法》与《网络安全法》，通过匿名化处理、加密存储与访问控制等技术手段保障用户隐私；并提供透明的数据使用说明与可控的隐私设置，增强公众对平台的信任。平台还将支持多语言与多文化内容推荐，促进音乐文化的跨境传播，具有积极的社会价值。

技术可行性方面，系统所需技术已在学术与工业界得到充分验证。SpringBoot提供了成熟的微服务开发与部署生态；Kafka与Redis等消息与缓存中间件具备高吞吐量与低延迟特性；Spark Streaming与MLlib能够高效处理大规模日志数据并完成离线模型训练；TensorFlow或PyTorch可在GPU集群上实现深度学习模型的训练与推理。多模态特征融合与图神经网络等算法已在公开数据集上表现出色，可直接迁移至本平台。系统架构采用容器化与Kubernetes编排，能够实现自动化部署、滚动升级与灰度发布，降低运维复杂度。鉴于上述技术的成熟度与可扩展性，本平台在技术实现层面具备高度可行性。

八、功能分析

系统功能模块可分为七大核心子系统，分别为用户服务子系统、音乐资源服务子系统、推荐服务子系统、数据采集与特征工程子系统、模型训练与管理子系统、在线推理与服务治理子系统以及监控与日志聚合子系统。

用户服务子系统负责管理用户身份认证、授权以及用户画像的动态维护。该模块提供注册登录接口，支持多种社交账号登录，并通过OAuth2.0协议实现统一鉴权；同时，用户画像模块将收集到的行为日志进行聚合，计算兴趣标签、情感倾向与播放习惯，并将结果存入Redis缓存，以供后续推荐服务快速调用。

音乐资源服务子系统主要维护音乐元数据与音频文件的管理。它提供音乐信息查询接口，支持按歌手、专辑、风格等多维度检索；同时，该子系统负责音频文件的分片存储与访问控制，并通过对象存储服务提供高可用的下载与流式播放能力。

推荐服务子系统是平台的核心功能模块，包含离线模型推理与在线实时推理两大功能。离线推理部分根据用户画像与音乐特征向量，调用多模态融合模型生成候选列表，并通过排序算法进行最终推荐；在线实时推理则在用户发起播放请求时，利用GPU加速的推理引擎即时计算相似度得分，并返回个性化推荐结果。该子系统同时集成可解释性模块，能够为每条推荐生成关键特征说明或可视化图表，以提升用户信任度。

数据采集与特征工程子系统负责从前端应用、移动端以及第三方音乐平台实时收集用户行为日志，并将其写入Kafka主题。Spark Streaming对日志进行解析，提取时间戳、用户ID、歌曲ID及操作类型等字段；随后调用音频处理库对原始音频文件进行MFCC、节奏与情感特征提取，并利用自然语言处理技术对歌词文本进行分词与情感分析；所有特征被统一映射到向量空间，存储于HDFS或对象存储中，为离线模型训练提供高质量输入。

模型训练与管理子系统采用Spark MLlib或TensorFlow框架，在GPU集群上完成多模态融合模型的离线训练。训练完成后，模型权重被上传至Model Registry，并通过版本控制与元数据管理实现模型生命周期管理；同时，系统支持在线A/B测试与灰度发布，以确保新模型在实际业务中的稳定性与性能提升。

在线推理与服务治理子系统负责将最新模型加载到推理引擎中，并通过RESTful或gRPC接口向前端提供推荐服务。该子系统集成缓存层（Redis）以快速获取用户嵌入向量与歌曲特征向量；采用Circuit Breaker与重试机制保证服务可用；同时，API网关统一管理鉴权、流量控制与熔断策略，实现微服务的弹性伸缩。

监控与日志聚合子系统使用Prometheus收集系统指标，并通过Grafana进行可视化；ELK堆栈负责日志聚合与异常分析；同时，安全审计模块记录关键操作日志，满足合规要求。

通过上述七大功能模块的协同工作，平台能够实现从数据采集、特征工程、模型训练、在线推理到服务治理与监控的完整闭环，为用户提供高质量、低延迟且可解释的音乐推荐体验。

九、数据库设计

User表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
user_id | 用户唯一标识 | 36 | VARCHAR(36) | PK | UUID形式生成
user_name | 用户昵称 | 50 | VARCHAR(50) ||
email | 邮箱地址 | 100 | VARCHAR(100) ||
password_hash | 密码哈希值 | 64 | CHAR(64) ||
created_at | 注册时间戳 | 19 | DATETIME ||
updated_at | 最后更新时间戳 | 19 | DATETIME ||

Artist表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
artist_id | 艺术家唯一标识 | 36 | VARCHAR(36) | PK ||
name | 艺术家姓名或艺名 | 100 | VARCHAR(100) ||
bio | 简短介绍或传记信息 | 255 | VARCHAR(255) ||
created_at | 创建时间戳 | 19 | DATETIME ||

Album表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
album_id | 专辑唯一标识 | 36 | VARCHAR(36) | PK ||
artist_id | 所属艺术家标识 | 36 | VARCHAR(36) | FK → Artist.artist_id ||
title | 专辑标题 | 200 | VARCHAR(200) ||
release_date | 发行日期 | 10 | DATE ||
created_at | 创建时间戳 | 19 | DATETIME ||

Song表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
song_id | 歌曲唯一标识 | 36 | VARCHAR(36) | PK ||
album_id | 所属专辑标识 | 36 | VARCHAR(36) | FK → Album.album_id ||
title | 歌曲标题 | 200 | VARCHAR(200) ||
duration_ms | 时长（毫秒） | 10 | BIGINT ||
genre | 音乐流派或类别 | 50 | VARCHAR(50) ||
created_at | 创建时间戳 | 19 | DATETIME ||

Playlist表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
playlist_id | 播放列表唯一标识 | 36 | VARCHAR(36) | PK ||
user_id | 所属用户标识 | 36 | VARCHAR(36) | FK → User.user_id ||
title | 播放列表标题或名称 | 200 | VARCHAR(200) ||
is_public | 是否公开（0/1） | 1 | TINYINT ||
created_at | 创建时间戳 | 19 | DATETIME ||

User_Song_Interaction表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
interaction_id | 交互唯一标识 | 36 | VARCHAR(36) | PK ||
user_id | 用户标识 | 36 | VARCHAR(36) | FK → User.user_id ||
song_id | 歌曲标识 | 36 | VARCHAR(36) | FK → Song.song_id ||
interaction_type | 交互类型（play/like/favorite） | 10 | VARCHAR(10) ||
timestamp | 交互时间戳 | 19 | DATETIME ||

Song_Feature表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
song_id | 歌曲标识（主键） | 36 | VARCHAR(36) | PK, FK → Song.song_id ||
mfcc_features | MFCC特征向量（序列化存储） | 65535 | MEDIUMBLOB ||
tempo | 节奏速度（BPM） | 10 | FLOAT ||
key_signature | 调性（整数表示） | 3 | INT ||

Lyrics_Feature表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
song_id | 歌曲标识（主键） | 36 | VARCHAR(36) | PK, FK → Song.song_id ||
sentiment_score | 情感得分（-1到1） | 10 | FLOAT ||
keywords | 关键词列表（逗号分隔） | 255 | VARCHAR(255) ||

Recommendation_History表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
rec_id | 推荐记录唯一标识 | 36 | VARCHAR(36) | PK ||
user_id | 用户标识 | 36 | VARCHAR(36) | FK → User.user_id ||
song_id | 推荐歌曲标识 | 36 | VARCHAR(36) | FK → Song.song_id ||
rec_time | 推荐时间戳 | 19 | DATETIME ||
score | 推荐得分（模型输出） | 10 | FLOAT ||

Model_Version表
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
model_id | 模型版本唯一标识 | 36 | VARCHAR(36) | PK ||
name | 模型名称（如“HybridRecommender”） | 100 | VARCHAR(100) ||
version | 版本号（如“v1.0.3”） | 20 | VARCHAR(20) ||
created_at | 创建时间戳 | 19 | DATETIME ||
description | 模型描述或备注信息 | 255 | VARCHAR(255) ||

以上表结构遵循第一范式与第二范式，避免冗余；主键与外键关系清晰，满足数据完整性约束。

十、建表语句

CREATE TABLE User (
user_id VARCHAR(36) NOT NULL,
user_name VARCHAR(50) NULL,
email VARCHAR(100) NULL,
password_hash CHAR(64) NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (user_id),
UNIQUE KEY idx_user_email (email)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Artist (
artist_id VARCHAR(36) NOT NULL,
name VARCHAR(100) NULL,
bio VARCHAR(255) NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (artist_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Album (
album_id VARCHAR(36) NOT NULL,
artist_id VARCHAR(36) NOT NULL,
title VARCHAR(200) NULL,
release_date DATE NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (album_id),
KEY idx_album_artist_id (artist_id),
CONSTRAINT fk_album_artist FOREIGN KEY (artist_id) REFERENCES Artist(artist_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Song (
song_id VARCHAR(36) NOT NULL,
album_id VARCHAR(36) NOT NULL,
title VARCHAR(200) NULL,
duration_ms BIGINT UNSIGNED NULL,
genre VARCHAR(50) NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (song_id),
KEY idx_song_album_id (album_id),
CONSTRAINT fk_song_album FOREIGN KEY (album_id) REFERENCES Album(album_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Playlist (
playlist_id VARCHAR(36) NOT NULL,
user_id VARCHAR(36) NOT NULL,
title VARCHAR(200) NULL,
is_public TINYINT(1) DEFAULT 0,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (playlist_id),
KEY idx_playlist_user_id (user_id),
CONSTRAINT fk_playlist_user FOREIGN KEY (user_id) REFERENCES User(user_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE User_Song_Interaction (
interaction_id VARCHAR(36) NOT NULL,
user_id VARCHAR(36) NOT NULL,
song_id VARCHAR(36) NOT NULL,
interaction_type VARCHAR(10) NULL,
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (interaction_id),
KEY idx_interaction_user_song (user_id,song_id),
CONSTRAINT fk_interaction_user FOREIGN KEY (user_id) REFERENCES User(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_interaction_song FOREIGN KEY (song_id) REFERENCES Song(song_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Song_Feature (
song_id VARCHAR(36) NOT NULL,
mfcc_features MEDIUMBLOB NULL,
tempo FLOAT NULL,
key_signature INT NULL,
PRIMARY KEY (song_id),
CONSTRAINT fk_song_feature_song FOREIGN KEY (song_id) REFERENCES Song(song_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Lyrics_Feature (
song_id VARCHAR(36) NOT NULL,
sentiment_score FLOAT NULL,
keywords VARCHAR(255) NULL,
PRIMARY KEY (song_id),
CONSTRAINT fk_lyrics_feature_song FOREIGN KEY (song_id) REFERENCES Song(song_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Recommendation_History (
rec_id VARCHAR(36) NOT NULL,
user_id VARCHAR(36) NOT NULL,
song_id VARCHAR(36) NOT NULL,
rec_time DATETIME DEFAULT CURRENT_TIMESTAMP,
score FLOAT NULL,
PRIMARY KEY (rec_id),
KEY idx_rec_user_song (user_id,song_id),
CONSTRAINT fk_rec_user FOREIGN KEY (user_id) REFERENCES User(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_rec_song FOREIGN KEY (song_id) REFERENCES Song(song_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE Model_Version (
model_id VARCHAR(36) NOT NULL,
name VARCHAR(100) NULL,
version VARCHAR(20) NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
description VARCHAR(255) NULL,
PRIMARY KEY (model_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻