sql - 数据规范化在什么时候变得可笑？

Question

在创建数据库和关系时，我经常发现自己在尝试规划 future 可扩展性时是否采取了正确的方法。

我有以下情况:

我有一个 Donor表和 Recipient table 。两个表共享公共(public)信息，例如 first_name , last_name , email_address , date_of_birth等等。如果您原谅我的面向对象语言，两者似乎都共享一个共同的抽象类型 Person。 .有可能某个人曾经是 Recipient以后可能会变成 Donor通过捐赠，所以重要的是信息不要跨表重复。我应该选择继承模式，还是应该只选择外键 Donor s 和 Recipient转至 Person table ？

最初，我想简单地映射属性，如 email_address和街道地址属性直接放入需要它们的事物中，但随后可能会出现一个人拥有多个电子邮件地址或邮寄地址(即:家庭、工作等)的可能性。这意味着我们有一个有点像这样的模型:

create table person(id int primary key auto increment, ..., 
    default_email_address);

create table email_address(id int primary key auto increment, 
    email varchar(255), name varchar(255), is_default bool, person_id int);

正如您可以想象的那样，这使事情变得有些复杂。 name字段还涉及默认值列表以及允许自定义输入。我不能把它变成一个枚举字段，因为有可能有人要添加很多电子邮件，而这一切都可能不同......(这就是我尖叫的地方“它甚至还值得吗？ !？!？”并对项目感到沮丧)

我想这真正归结为以下几点:数据规范化在什么时候变得可笑？我的目标是创建一个非常好的尽可能向前兼容的数据模型，我不会因为以后创建而自责。

Answer 1

at what point does data normalization become ludicrous?

在它停止对实际需求进行建模时。

举个例子:

与 Donor和 Recipient表，如果任何一个人都极有可能成为两者，那么分离到 Person 是有意义的。实体。如果这是罕见的，它不会。

与 email_address和 street_address情况下，这取决于您是否需要存储倍数(期望是什么？)。您可能希望为每个业务单位存储单独的版本(例如 shipping_address 与 billing_address )。