我正在MySQL中为应用程序创建一个新的数据库，并想知道是否有人可以就以下设置提供一些建议。我会尽可能地尽量简化事情。
此数据库旨在存储与用户创建的特定项目相关的警报。反过来，需要存储与项目和/或警报相关的注释。起初我考虑了以下结构...
USERS表 - 用于存储基本的应用用户信息（例如user_id。名称，电子邮件） - 这是我确定不需要更改的唯一位
ITEMS表：包含特定项目的信息（4个字段左右）。包含user_id以指示哪个用户创建/拥有此项目
ALERTS表：包含警报信息，item_id表示警报与哪个项目相关，包含user_id以指示哪个用户创建了警报
注释表：包含注释信息，注释所有者的user_id，如果与项目相关联，则为item_id，如果与警报相关联，则为alert_id
关系：
项目并不总是有与之关联的提醒 项目或警报并不总是有与之关联的注释
警报始终与项目相关联。可以将多个警报与同一项目相关联。
记事始终与项目或提醒相关联。可以将多个注释与同一项目或警报关联。
一旦首次创建的项目信息不太可能由用户更新。
为了论证，让我们说每个用户将平均创建10个项目，每个项目平均有2个与之关联的警报。每件商品/警报平均会有2个钞票。
将运行非常常见的查询：
1）返回特定用户创建的所有项目以及任何相关的警报和注释。给定user_id，此查询将跨越3个表
2）每天检查需要发送到用户电子邮件地址的警报。警报日期==今天，返回用户的电子邮件地址，项目名称和任何相关的注释。这需要一个跨越4个表的查询，这就是为什么我想知道我是否需要采取不同的方法......
选项1）一个表格，用于涵盖项目，警报和注释。每行的user_id所有者。每次向项目或警报添加注释时，都会重复警报和/或项目信息。似乎有点浪费，但项目和警报信息不会很大。
选项2）我没有预见到需要查询笔记（着名的最后一句话？）所以如何序列化笔记数据，以便将多个笔记存储在项目或警报表中的一行中（或者只是组合警报/项目表）
选项3）您还能想到其他什么？我问这个问题，因为我考虑的每个选项都不太合适。
我很欣赏这是一个小项目，因此性能不应该引起太大关注，我应该选择4个表格。我的常见查询最终会变得相对复杂，这让我觉得我需要重新评估结构。
答案 0 :(得分：1)
我想说，只有当绩效数据表明有必要时，常识才能规范化以启动和非规范化。
确保您的表已正确编入索引，并具有JOIN的外键关系。
如果您认为自己最终会获得大量数据，那么这可能是考虑分区策略的好时机。按时间对快速增长的表格进行分区将是一个很好的第一步。
答案 1 :(得分：0)
四张桌子并不复杂。我通常编写报表查询，在具有数百个表（大多数具有数百万条记录）的数据库结构中命中15个或更多表，我甚至不会说我们的dbs超过中等大小（我们系统中的典型数据库可能有大约200演出的数据，因此数据库的数据并不大。）因为它们被正确编入索引，所以除非我进行非常复杂的计算，否则它们仍然运行得很快规范化，甚至不考虑非规范化，直到您是一位经验丰富的数据库设计师，而不是担心表的数量。