我有一个数据库，其中有几个表有一列email用于存储电子邮件地址。因为这是用于调查的，所以很多值都是相同的，更可能与名称，地址等相同。
我应该只有一个主Emails表，然后是一个email_id列吗？这样我只存储一次电子邮件字符串，而不是多次存储在表中。但是，如果我想确定我只存储唯一的电子邮件，那么索引检查字符串的唯一性的长度是否有限制，因此我可以存储多个长电子邮件地址的副本？
在调查数据库中，我们存储他们提交的电子邮件地址。如果他们选择加入邮件列表，我们会将这些唯一的（每个成员身份一封电子邮件）存储在邮件列表成员资格表中，因此该表中可能有多个相同的地址，具体取决于他们加入的俱乐部数量。现在我正在添加一个表来跟踪退回电子邮件，因为这是电子邮件地址的属性，而不是调查或邮件列表成员资格。我在想，“这是很多字符串连接！”
这是“One True Lookup Table”的形式吗？
答案 0 :(得分：6)
我应该只有一个主电子邮件表，然后是一个email_id列吗？
实际上并不重要。
对索引检查字符串的唯一性的长度没有一些限制，因此我可以存储多个长电子邮件地址的副本吗？
没有。没有限制。独特意味着独特，而不是“某些随机限制”。
我在想，“这是很多字符串连接！”
所以？字符串连接并不是非常慢。如果你能证明这些字符串连接是你应用程序中最糟糕的瓶颈，那么用整数FK替换字符串连接可能会加快速度。
直到你能证明这些字符串连接是你最糟糕的问题，不要担心它们。
担心如何正确使用电子邮件地址的业务规则。在证明自己遇到问题之前不要进行优化。
答案 1 :(得分：0)
如果问题是“成员有电子邮件地址”，那么我会保留与该成员直接关联的电子邮件地址，而不是将其标准化为电子邮件表。这是因为并非所有“会员”都必须共享电子邮件。
如果（不要问我为什么，我不这样做 了解最终用户）两个成员 共享同一个电子邮件地址，什么 当其中一个发生变化时就会发生 他们的地址 - 但另一个 不想？
第二种情况，如果我的系统中有两个成员资格，两者都有 相同的电子邮件地址，然后我想将其中一个更改为其他地址？ （不要问我原因，我是最终用户，我已经说过我不了解最终用户。）
这将涵盖一个相当简单和直接的情况。如果您的系统不同，以至于您需要更多或更严格地控制电子邮件，那么规范化可能对您有用。诀窍在于，从数据的角度来看，它是重复可以规范化的数据，还是恰好包含一些重复值的“不同”数据。
Bounceback电子邮件表适用于任何一种方式，因为它是一种单独的数据（或一种电子邮件地址）。
至于字符串和索引长度，现在如果RDBMS声称它可以索引或唯一索引字符串最多X个字符（电子邮件地址到达多长时间？），您可以依赖它来执行此操作。它的执行速度可能不会太快，因为它必须按每个密钥4（典型的整数存储大小）处理X字节的数据，但它会起作用。