Mysql 在一个非常简单的数据库中，数据库规范化有多重要？
我正在制作一个非常简单的数据库（mysql），基本上有两种类型的数据，始终具有1:1的关系： 事件Mysql 在一个非常简单的数据库中，数据库规范化有多重要？,mysql,database,database-design,database-normalization,Mysql,Database,Database Design,Database Normalization,我正在制作一个非常简单的数据库（mysql），基本上有两种类型的数据，始终具有1:1的关系： 事件 主办方 时间（可选） 位置（城市、州） 地点（可选） 详细信息URL 赞助商 名字 网址 城市将经常被复制，但是对于这样一个简单的数据库模式，有一个Cities表真的有很大的价值吗 数据库通过屏幕抓取网站来填充。在这个站点上，城市字段是通过从下拉列表中选择来填充的，因此不会出现错误类型等，并且很容易将记录与城市表进行匹配。我只是不确定，即使我的数据库的用户会经常按城市搜索，也会有很大的意
- 主办方
- 时间（可选）
- 位置（城市、州）
- 地点（可选）
- 详细信息URL
- 名字
- 网址
城市将经常被复制，但是对于这样一个简单的数据库模式，有一个Cities表真的有很大的价值吗
数据库通过屏幕抓取网站来填充。在这个站点上，城市字段是通过从下拉列表中选择来填充的，因此不会出现错误类型等，并且很容易将记录与城市表进行匹配。我只是不确定，即使我的数据库的用户会经常按城市搜索，也会有很大的意义。我认为你看问题的角度是错误的-你应该总是正常化，除非你有充分的理由不这样做
信任您的应用程序来维护数据完整性是一个不必要的风险。您说数据是统一的，因为它是从下拉列表中选择的。如果有人入侵表单并修改数据，或者如果您的代码无意中允许使用同名的querystring参数，该怎么办？立即规范化数据库 在规范化数据上优化查询要比规范化一堆数据容易得多 你说现在很简单——这些东西有增长的趋势。正确地设计它，您将获得正确设计的经验和一些未来的证明。为什么不继续进行规范化？你写的时候好像正常化的成本大于收益。在填充它之前，以正常形式设置它要比以后尝试和规范化它容易得多 还有，我想知道你的一对一关系。天真地说，我会想象一个活动可能有多个赞助商，或者一个赞助商可能参与多个活动。但我不知道你的商业逻辑 预计到达时间： 我不知道为什么我以前没有注意到这一点，但是如果你真的不喜欢规范化你的数据库，并且你知道你的活动和赞助商之间总是有一对一的关系，那么为什么你会把赞助商放在一个单独的表中呢
听起来您可能对什么是标准化以及为什么要这样做有点困惑。为用户填充下拉框的城市数据来自哪里？你不想要一张桌子吗
看起来您将位置视为一个属性，包括城市和州。假设您想单独按州而不是按城市和州对事件进行排序或分析？如果您没有state的属性，那么这可能很难做到。从逻辑上讲，我希望状态属于城市表——尽管这可能取决于您想要识别城市的确切方式。直接回答：仅仅因为问题相对简单，就没有理由不做简单的事情。用脚走路比用手走路容易多了。我不记得曾经说过，“哦，我只需要走半英里，那是一段短距离，所以我还是用手走路好。” 更详细的回答：如果您没有保留城市名称以外的任何城市信息，并且没有预设的城市列表（例如，构建下拉列表），那么您的模式已经规范化。除了城市名称之外，城市表中还有什么？（我假设州不能依赖于城市，因为在不同的州可以有两个同名的城市，例如Dayton OH和Dayton TN。）规范化的相关规则是“无非键依赖性”，即不能有依赖于非键数据的数据。如果你有，比如说，每个城市的纬度和经度，那么这些数据将在引用同一个城市的每个记录中重复。在这种情况下，您肯定会希望分离出一个单独的城市表来保存纬度和经度。当然，您可以创建一个“城市代码”，它是链接到城市表的整数或缩写。但如果没有关于一个城市的其他数据，我看不出这有什么好处 从技术上讲，我认为城市取决于场地。如果地点是“洛克菲勒中心”，这意味着这个城市一定是纽约。但如果场地是可选的，这就产生了问题。一种可能是有一个场馆表，其中列出了场馆名称、城市和州，如果您没有指定场馆，则每个城市都有一个“未指定的”。这在教科书上更为正确，但在实践中，如果在大多数情况下不指定venu，它将不会有什么好处。如果大多数时候你确实指定了一个静脉，这可能是一个好主意
哦，还有，活动和赞助商之间真的有1:1的关系吗？我可以相信，一个活动不能有一个以上的赞助商。（在现实生活中，有很多活动有多个赞助商，但可能出于您的目的，您只关心一个“主要赞助商”或类似的人。）但赞助商是否从不举办多个活动？这似乎不太可能。答案取决于您是否希望在数据输入过程中防止错误。如果需要，您将需要一张场地表：
VENUES
City
State
VenueName