0

编辑后：哇，这个问题很长。请原谅=\

我正在创建一个包含 30 多列的新表。这些列主要由从下拉列表中进行的选择填充，并且它们的选项在很大程度上在逻辑上相关。例如，标记为 Review Period 的下拉菜单将包含每月、半年和每年等选项。我想出了一个可行的方法，通过创建一个原始查找表来将这些选项标准化为数字标​​识符，该表存储诸如每月、半年和每年等值。然后，我将这些原语的 ID 存储在记录表中，并使用视图将该表连接到我的查找表中。有了这个视图，记录表可以包含只有应用程序才能理解的原始数据，同时允许外部应用程序和管理员对视图运行 SQL 并返回转换为友好信息的数据。

只是变得复杂了。现在这些下拉列表将包含非逻辑相关的项目。例如，Review Period 下拉列表现在需要有 NA 和 Manual 选项。这将我的整个分组计划从水中吹了出来。

此应用程序中使用的类似结构已诉诸于跨多个记录存储重复的字符串值。这意味着您可以在表的 ReviewPeriod 列中存储数百条带有字符串“Monthly”的记录。自从我开始在这里工作以来，发生这种情况的想法让我感到畏缩，但现在我开始认为非标准化数据可能是这里的最佳选择。

我能想到的唯一另一种方法是使用我的初始方法，同时允许它是动态的，并支持随时向任何下拉列表不断添加新选项：将数据保存到数据库时，遍历每一个我的业务对象（在本例中为 .NET 类）的属性，并检查原始表中存在的任何字符串值。如果没有，则添加它并返回自动生成的唯一标识符以存储在记录表中。看起来很复杂，但这是为了规范化数据而要经历的事情吗？

4

2 回答 2

2

一切皆有可能。没有人会把你拖进非规范化监狱并吊销你的 DBA 卡。我想说你应该知道规则以及违反规则意味着什么。一旦你掌握了这些，就由你和你的最佳判断来做你认为最好的事情。

于 2012-05-04T18:15:50.547 回答
2

我想出了一个可行的方法，通过创建一个原始查找表来将这些选项标准化为数字标​​识符，该表存储诸如每月、半年和每年等值。然后，我将这些原语的 ID 存储在记录表中，并使用视图将该表连接到我的查找表中。

用 ID 号替换文本与规范化完全无关。您正在描述替代键而不是自然键的选择。有时代理键是一个不错的选择，而有时代理键是一个糟糕的选择。（通常是一个比你想象的糟糕的选择。）

这意味着您可以在表的 ReviewPeriod 列中存储数百条带有字符串“Monthly”的记录。自从我开始在这里工作以来，发生这种情况的想法让我感到畏缩，但现在我开始认为非标准化数据可能是这里的最佳选择。

将字符串“Monthly”存储在多行中与规范化无关。（或使用非规范化。）这似乎与规范化意味着“用 id 号替换所有文本”的概念有关。在您的数据库中存储文本不应该让您畏缩。VARCHAR(n) 的存在是有原因的。

我能想到的唯一另一种方法是使用我的初始方法，同时允许它是动态的，并支持随时向任何下拉列表不断添加新选项：将数据保存到数据库时，遍历每一个我的业务对象（在本例中为 .NET 类）的属性，并检查原始表中存在的任何字符串值。如果没有，则添加它并返回自动生成的唯一标识符以存储在记录表中。

让我们非正式地考虑一下这个问题。

外键提供参照完整性。它们的目的是限制列中允许的值。非正式地，引用的表提供了一组有效值。不在该表中的值不允许出现在其他表的引用列中。

但无论用户输入什么，您都将其添加到该有效值表中。

如果您首先要接受用户输入的所有内容，为什么还要使用外键？

这里的主要问题是那些教你（错误地教给你）关系模型的人对你的服务很差。（而且，可能，教你 SQL 的人也同样糟糕。）我希望你能很快摆脱那些错误的观念，并很快取得真正的进步。

于 2012-05-04T23:30:33.047 回答