问mysql设计:冗余表

EN

不完全清楚您显示的是什么，但我敢猜第一个设计没有列出特定的地址列，所以想法是更通用。第一种设计更容易扩展，您只需添加一个新的field_id和字段数据，而不是添加列。话虽如此，你和其他使用它的人可能会发现使用它更痛苦……

而不是像这样的东西：

SELECT street1, street2, city, postal_code FROM address where user_id = someval

您将执行以下操作：

SELECT field_id, field_data FROM fields WHERE field_id in 
('street1', street2', 'city', 'postal_code') 
AND user_id = someval

在第一种情况下，在程序中为结果赋值变量可能更容易一些，在第二种情况下，这可能会有点麻烦(取决于语言)，因为您可能必须测试每个field_id以查看它包含什么。

在大多数情况下，我认为您应该使用第二种方法-特别是如果您事先知道大多数字段是什么。当您认为以后需要添加许多以前未知和未知的字段时，第一种方法更适用。

您概述的第一种方法是“属性包”；它意味着将针对您的用户存储的数据集缺乏结构。第二种方法更像是一种结构化方法，其中您有一个包含特定条目的特定地址表，等等。

您所拥有的数据类型确实决定了哪种方法是合适的。对于大部分非结构化或不确定的数据，属性包方法是非常合适的；但是，如果您知道每个用户肯定会有一个地址，并且地址的结构将采用精确的形式，那么在这种情况下，有一个地址表是有意义的，该表具有特定的值列。

确定这些类型的结构中哪种类型是合适的，实际上是关于您将接收的数据以及其中固有的结构(如果有)的一些知识或期望。我经常看到这两种方法的混合，在这种情况下，每个记录都有一组众所周知的、结构良好的数据，还有一组(潜在的)非结构化数据可以(但可能不)添加到记录中。

编辑:为了解决具体的性能问题，是的，当表在第一种情况下变得很大时，性能可能会成为一个问题。甚至在表变得很大之前，性能就会成为一个问题，这取决于您需要运行的查询类型。使用属性包方法限制了您使用索引来加快查询速度的能力(例如，对邮政编码进行索引)。

第二种方法更好-原因是：

1. 你的地址表定义了地址是什么，所以它很容易更改，而不需要更改每个使用地址的表，
2. 如果你发现每个用户需要多个地址，它更整洁，并允许用户为每个地址指定别名。亚马逊做到了这一点。下面是您的表可能的样子：

下面是一个示例db结构

create table user (
user_id int,
home_address_id,
postal_address_id
...
);

create table address (
address_id int,
alias text, -- what the user calls this - eg "Uncle bob's house"
street text,
suburb text,
...
);

create table sale (
sale_id int,
user_id int,  -- actually, this is not required since you can go via address, but leave it
delivery_address_id int,
...
}

这将允许用户将内容发送到其他可重复使用的地址-也许我总是在圣诞节时给鲍勃叔叔送礼物-没问题-我在我的选择列表中有他的地址。