我有一个数据库，它有一个表 email_eml，它存储 3 个属性 name_eml、host_eml 和 domain_eml。哪个存储电子邮件名称网站名称和域名（如 .com .net 等） 它不存储 @ 或 . 在任何变量中。这给了我一些灵活性（例如检查平均名称长度（在@符号之前）会更快）。我可以收集有关电子邮件名称的一些统计信息，还可以从 name_eml 属性创建用户名。然而，当人们提交他们的电子邮件或者我必须比较整封电子邮件时，这也是一个负担。这将使我存储额外的 @ 和 . 当我想收集统计数据时，让我通过脚本分隔名称。
我想知道将电子邮件存储在单列而不是 3 列中是否更好。其中一种方式是更合适还是更规范化的方式？
我希望答案包括两种存储电子邮件地址的方法的优缺点。（即使将电子邮件存储在 3 列中也没有很多优点）
它不存储 @ 或 a 。在任何变量中。
好吧，它应该；cat.call@somedomain.com是合法的电子邮件地址。
我想知道将电子邮件存储在单列而不是 3 列中是否更好。其中一种方式是更合适还是更规范化的方式？
这与标准化没有任何关系。它与复杂的数据类型有关。
关系模型允许任意复杂的数据类型。常用的复杂数据类型是时间戳，通常包括年、月、日、小时、分钟、秒和微秒。
给定时间戳，有时您可能只需要知道日期，有时您可能只需要知道年份或小时。在处理复杂的数据类型时，关系模型给 dbms 带来了特定的负担。对于复杂的数据类型，dbms 要么完整地返回它，要么提供返回其各个部分的函数。关键是，如果用户只想要时间戳中的小时，则用户不需要编写代码来获取它。
SQL dbms 对时间戳有很好的支持；我熟悉的每个 dbms 都提供了返回时间戳各个部分的函数。他们都没有对电子邮件地址的原生支持。
在 SQL 平台上，您至少有两种选择可以使您的数据库接近关系模型。您可以编写可以合并到数据库服务器中的函数（如果您的 dbms 和您的编程技能允许的话），或者您可以将数据类型拆分为多个部分，以便可以像任何其他值一样完整地处理每个部分。
虽然可能有一些数据类型可以像这样拆分（街道地址可能是其中之一），但我真的没有看到拆分电子邮件地址的任何令人信服的理由。
这给了我一些灵活性（例如检查平均名称长度（在@符号之前）会更快）。我可以收集有关电子邮件名称的一些统计信息，还可以从 name_eml 属性创建用户名。
虽然这是真的，但现在我无法想象用户名的平均长度有什么有趣的地方。我不认为你的任何理由令人信服，但你比我更了解你的申请。
如果您确实需要对这些片段进行大量操作，那么将这些片段分开会更有意义。更“正常”的客户端代码应该通过连接各个部分的视图来访问电子邮件地址。（连接比在运行时解析电子邮件地址要容易得多。）
将电子邮件地址存储在三列中的情况极为罕见。如果您想在@符号之前的电子邮件部分进行搜索，您可以使用 LIKE 查询...
SELECT email FROM people WHERE email LIKE 'john.smith@%';
我很想听听任何无法使用 SQL 查询的真实示例。
在规范化方面，一旦你分解了公共方面（例如主机，尤其是顶级域），它们应该被建模为外部关系。所以你最终得到了三个表：
emailNames 然后有三列：
请注意，我使用了“TLD”，因为这可能是主机名中唯一有显着重叠的部分，您可以期待“。” TLD 开始之前的主机名中的字符。