)
★ FEATURED ARTICLE 博主介绍✌ 专注于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)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方获取联系方式
阅读完成 · 觉得有帮助？
)
)
