1

我目前有一个Users表，其中包含以下列：

  1. 用户身份
  2. 地址

目前我们将 IP 地址存储在Address列中。展望未来，我们需要存储一个 MAC 地址。将它们都存储在同一列中（两者都是varchar）并用另一列指示它是什么类型，typeOfAddress int用 1 或 2 指示地址类型，这是一个好习惯吗？或者我应该创建一个单独的可为空列（并将现有列更改为可为空）

4

6 回答 6

7

不，这不是好习惯。几十年前我被告知的第一件事是“计算机领域不应该用于多个目的”。否则，您原则上无法知道它的含义，除非您有另一个指标字段，您也可以将其用于其他值类型，并且您正在引入完全不必要的误解风险。

于 2013-03-05T21:47:43.240 回答
1

绝对创建一个单独的可为空列。这将使您在此表上编写所有未来的 SQL 变得更加容易，并使所有内容总体上更易于维护。

于 2013-03-05T21:48:38.713 回答
1

好吧，根据给出的信息，这取决于。

用户会同时拥有 IP 地址和 MAC 地址吗？如果是这样，您需要将这些记录放在与用户记录具有外键关系的单独表中。

检索呢？在检索有关用户的数据时，是否经常需要检索这些值？如果这样做，将它们存储在同一个表中并避免每次都进行表连接可能是有意义的。

我倾向于有两个单独的列，一个 forIpAddress和一个 for MacAddress。这样就可以清楚地知道哪一列中有哪些数据，而无需查找另一列来找出它。

于 2013-03-05T21:51:03.023 回答
0

推荐这种结构：

  1. 用户身份
  2. 地址类型
  3. 地址

因为它在第三个NF。

在单个表中简单地使用多个列的缺点是：

  • 每当过滤地址时需要记住“空句柄”
  • 随着时间的推移，随着新地址类型的添加，该范式可能会超出意义；但是转换成本太高而无法考虑。

应添加带有 FK 关系的 AddressType 表，以防止意外输入看起来有效但实际上无效的 AddressType。

最重要的是，理论上，每个 AddressType 都有一个单独的表，在 UserId 上链接到用户表；但这对于所提出的问题确实看起来有点矫枉过正。

于 2013-03-05T21:47:51.307 回答
0

如果您认为您不会添加更多不同类型的地址，我更喜欢有两列。我认为它在概念上更简单，查询也更简单。但是，如果您认为要添加更多类型的“地址”（无论可能是什么），那么拥有 5 或 6 个不同的列可能并不理想。在这种情况下，我会使用一个地址列和一个地址类型列，并创建一个定义地址类型的联结表。

于 2013-03-05T21:49:08.743 回答
0

不要创建新列，而是创建一个新表地址和地址类型，链接到这些：

Users
foreign key address_id

Address
id
value (varchar)
foreign key adress_type_id

AddressType
id
name (varchar)

可能有点矫枉过正，但这是一种很好的标准化做法

于 2013-03-05T21:52:11.737 回答