0

在我的职业生涯中，我看到了两种不同的设计，如何在 DB 中为业务对象建模：

  1. 始终使用 Long 作为实体的 ID
  2. 尽可能选择最合适的。

现在，我们有了可以从另一个服务下载的“资源”实体。每个资源都包含自然ID电子邮件（电子邮件只是一个例子，我们可以想象其他情况应该使用String）。我想将它用作数据库中的主 ID。但我的同事想创建额外的属性 - Longid。我不确定，我为什么要创建这个附加属性。当然，DB 模型更简单，因为所有实体都具有相同的结构，但我更喜欢使用Stringid。

伙计们，您认为哪种型号更好，为什么？

4

4 回答 4

1

迈克尔，

电子邮件和此类字符数据列可能不是 ID 的正确选择，因为区分大小写取决于所使用的数据库实现和/或排序规则。您希望 user@server.com 和 USER@SERVER.COM 给您相同的结果吗？是否可能取决于您选择的数据库/操作系统/排序规则。当您拥有基于字符数据的 ID 时，您会默默地将这些关注点从应用程序推送到数据库管理和排序配置。

这可能很好，因为它只是一次性活动，您的数据库管理员可以为您设置它，但通常情况下，您必须为不同的操作系统和数据库维护单独的数据库脚本。

在我看来，这没有经验法则，您必须根据情况做出最佳判断。

于 2013-08-02T11:47:08.650 回答
1

我原则上同意您应该尽可能使用自然 ID，尽管在这种情况下电子邮件可能不是一个好的候选者。自然 ID 应该是不可变的，即它们永远不应该改变。如果系统有可能需要更改/取消电子邮件与资源的关联，那么您实际上是在更改记录的身份。

如果是我，并且没有其他潜在的自然身份；使用唯一编号。在这种情况下，它不会增加任何不必要的复杂性，并为未来围绕电子邮件属性的需求更改留出空间。

于 2013-08-02T11:26:46.163 回答
1

首先，我不确定是否假设电子邮件可以是“资源”的唯一自然 ID，因为这意味着对于每个新资源，您需要创建一个新电子邮件并且资源无法阅读电子邮件，但我知道案例，所以这可能是正确的。

所以对于这个问题：

影响

  • 在任何情况下，数字 ID 的查找速度都更快。但是由于字符串也非常快（当使用适当的索引时），这对于大多数应用程序来说可能已经足够了。
  • 数字 ID 使用更少的空间（这通常是最少的问题）
  • 在涉及异构系统的情况下，通常首选字符串 ID（您可以在示例中看到：服务提供带有字符串 ID 的“资源”）。这样做的一个原因是它更容易调试，例如，用户可能一眼就能看出引用的是什么对象，另一个原因是字符串是几乎所有系统中最常见的分母（尽管存在编码问题^^）。
  • 如果您必须在数据库中进行大量手动工作，您可以更快地键入数字，因为字符串往往更长
  • 如果您使用自然 ID，则很常见的情况是 id 包含多个列。这使得 SQL 语句更长且更容易出错，就像它使对象关系映射器配置更长且更容易出错一样。
  • 您通常有一些唯一标识符（例如电子邮件），但可能会随着时间而改变（人们结婚^^）。在这些情况下，添加一些人工 id 也是很常见的（两者都有）

在您的情况下，除了使用该字符串 id 与该服务进行通信之外，您别无选择（？），因此您至少也必须拥有它。

所以现在我自己的意见是：我认为作为一名开发人员，你的工作量更少，数字 ID 的问题也更少，尽管调试有点困难。作为数据库管理员，如果您只有一列，那么它是 String 还是 Long 都没有关系，因为它不会使连接复杂化。只要字符串是不可变的，例如永远不会改变，你就可以了。如果它可以改变它肯定会让你作为管理员很头疼（愚蠢的开发人员不会在意一点^^）。如果它可能随时间变化，请使用数字 ID。

于 2013-08-02T11:36:38.347 回答
0

除了已经提到的论点之外，您还可以搜索“代理键”或访问有关此主题的 Wikipedia 页面http://en.wikipedia.org/wiki/Surrogate_key，其中列出了许多优点和缺点。

于 2013-08-02T11:39:29.247 回答