2

我正在制作一个非常简单的数据库（mysql），其中包含两种类型的数据，始终具有 1 对 1 的关系：

活动

  • 赞助
  • 时间（可选）
  • 位置（城市，州）
  • 场地（可选）
  • 详细信息网址

赞助商

  • 姓名
  • 网址


城市会经常被复制，但是对于这样一个简单的数据库模式来说，拥有一个城市表真的有很大的价值吗？

该数据库是通过对网站进行屏幕抓取来填充的。在这个站点上，城市字段是通过从下拉列表中选择来填充的，因此不会出现输入错误等情况，并且很容易将记录与城市表匹配。即使我的数据库的用户会经常按城市搜索，我也不确定是否会有很大的意义。

4

7 回答 7

14

现在规范化数据库。

优化对规范化数据的查询比规范化一堆数据要容易得多。

你说现在很简单——这些东西有增长的趋势。正确设计它，您将获得正确设计的经验和一些未来的证明。

于 2010-09-20T14:50:55.613 回答
4

我认为您以错误的方式看待事物-除非您有充分的理由不这样做，否则您应该始终正常化。

信任您的应用程序来维护数据完整性是一种不必要的风险。您说数据是统一的，因为它是从下拉列表中选择的。如果有人破解了表单并修改了数据，或者您的代码无意中允许了同名的查询字符串参数，该怎么办？

于 2010-09-20T14:50:22.743 回答
1

为用户填充下拉框的城市数据来自哪里？你不想要一张桌子吗？

看起来您将位置视为一个属性，包括城市和州。假设您想仅按州而不是按城市和州对事件进行排序或分析？如果您没有状态属性，那可能很难做到。从逻辑上讲，我希望州属于城市表-尽管这可能取决于您要如何识别城市。

于 2010-09-20T16:04:32.723 回答
1

直接回答：仅仅因为一个问题相对简单，没有理由不做事情来保持简单。用脚走路比用手走路容易得多。我不记得曾经说过，“哦，我只需要走半英里，那是很短的距离，所以我还不如用手走路。”

更长的答案：如果您除了名称之外没有保留有关城市的任何信息，并且您没有预先设置的城市列表（例如构建下拉列表），那么您的模式已经标准化。除了城市名称之外，City 表中还有什么？（我假设 State 不能依赖于 City，因为你可以在不同的州有两个同名的城市，例如 Dayton OH 和 Dayton TN。）规范化的相关规则是“没有非关键依赖”，也就是说，你不能具有依赖于非键数据的数据。例如，如果您有每个城市的纬度和经度，那么这些数据将在引用同一城市的每条记录中重复。在这种情况下，您肯定会想打破一个单独的城市表来保存纬度和经度。当然，您可以创建“城市代码” 这是一个链接到城市表的整数或缩写。但是如果没有关于一个城市的其他数据，我看不出这有什么好处。

从技术上讲，我会假设 City 取决于 Venue。如果场地是“洛克菲勒中心”，那暗示城市一定是纽约。但如果场地是可选的，就会产生问题。一种可能性是有一个列出场地名称、城市和州的 Venue 表，对于未指定场地的情况，每个城市都有一个“未指定”。这将更符合教科书的正确性，但在实践中，如果在大多数情况下你不指定一个地点，它会收获很少。如果大多数时候您确实指定了一个地点，那可能是一个好主意。

哦，而且，活动和赞助商之间真的有 1:1 的关系吗？我可以相信一个活动不能有多个赞助商。（在现实生活中，有很多活动有多个赞助商，但也许出于您的目的，您只关心“主要赞助商”之类的。）但是赞助商从不举办多个活动吗？这似乎不太可能。

于 2010-09-20T17:02:53.743 回答
0

为什么不继续正常化？你写的好像标准化的成本超过了收益。在填充之前将其设置为正常形式比稍后尝试对其进行规范化更容易。

另外，我想知道你的一对一关系。天真地，我会想象一个活动可能有多个赞助商，或者一个赞助商可能参与多个活动。但我不知道你的业务逻辑......

ETA： 我不知道为什么我之前没有注意到这一点，但如果你真的不喜欢规范化你的数据库，并且你知道你将永远在活动和赞助商之间建立一对一的关系，那么为什么你会把赞助商放在一个单独的桌子上吗？

听起来您可能对什么是标准化以及为什么要这样做有点困惑。

于 2010-09-20T14:55:37.477 回答
0

IMO 的答案取决于您是否想在数据输入过程中防止错误。如果这样做，您将需要一个 VENUES 表：

VENUES
City
State
VenueName

以及 CITIES 和 STATES 表。（注意：我见过同一个城市在同一个州多次出现的情况，通常是较小的城镇，因此 CITY/STATE 不包含唯一的二元组。通常有一个邮政编码来消除歧义。）

为防止数据输入操作员进入 NY NY 的场所，该场所实际上位于 SF CA，您需要验证场所条目以查看记录中提供的城市/州是否存在此类场所。

然后你需要强制 CITY/STATE，并且必须编写代码来回滚事务并处理错误。

如果您不关心强制执行这种准确性，那么您实际上也不需要 CITY 和 STATES 表。

于 2010-09-20T17:17:45.853 回答
0

如果你有兴趣了解规范化，你应该了解当你不规范化时会发生什么。对于每个范式（超过 1NF），都会出现一个更新异常，这是由于有害冗余而发生的。

通常可以围绕更新异常进行编程，有时这比始终归一化到最终程度更实用。

有时，由于未能规范化以及未能对应用程序进行编程以进行补偿，数据库可能会进入不一致的状态。

在你的例子中，我能想到的最好的就是一种蹩脚的假设。如果一个城市的名字在一行中拼写错误，但在所有其他地方都拼错了怎么办。如果您按城市和赞助商进行汇总呢？您的输出将反映错误，并将一组分为两组。如果这个城市在数据库中只拼写一次，也许会更好或更坏。即使名称拼写错误，至少摘要的分组是正确的。

这值得规范化吗？嘿，这是你的项目，不是我的。你决定

于 2010-09-20T19:35:12.153 回答