问题标签 [surrogate-key]

数据库类型：mysql

列：日期、时间、价格 1、数量 1、价格 2、数量 2 时间将以毫秒为单位，一个月的记录数约为 550 万。

我不能选择日期作为主键，因为它不是唯一的，但可以选择日期和时间组合，但这也不是一个好主意。

我将在“这个日期和时间”和“那个日期和时间”之间运行诸如选择价格和数量之类的查询，结果可能在数百万范围内。

就主键、索引和代理键而言，什么是最佳选择，以及实现这一点的最佳方式是什么。我应该如何优化数据库。

我有一个巨大的数据库，它存储来自不同数据源（如两个不同论坛）的线程和帖子。对于每个数据源，实体的 ID（例如 ThreadId、PostId...）是唯一的，但它可能与另一个数据源获得的实体的 Id 冲突。例如，forum1 和 forum2 都可以有一个 Threadid=1 的线程：

我正在使用 Linq2Sql 和存储库模式将我的应用程序连接到数据库。我读到使用 Linq2Sql 时应避免使用复合键（在 ThreadId 和 DatasourceId 之间）。因此，我想代理主键是我唯一的选择（是吗？）：

表线程：

• UniqueId - 整数，PK
• DatasourceId - 整数
• ThreadId - 整数
• ...

表帖：

• UniqueId - 整数，PK
• DatasourceId - 整数
• PostId - 整数
• ThreadId - int，FK 到 Threads.ThreadId

现在，我的问题是：Linq2Sql 是否能够在其生成的类中映射帖子和线程之间的 1:1 关系？如果帖子具有 Thread.ThreadId 的外键并且有两个实体具有相同的 ThreadId（当然是不同的 DatasourceId），会发生什么？我想这将在帖子上返回一组分配的线程 - 我不想要！我还能以某种方式为每个帖子返回一个共享相同 DatasourceId 的帖子吗？

I am building a list type to let users make lists of various things in my system. The list elements therefore need references to both the type and identifier of the things they will be pointing at.

For instance, I will allow users to make lists of products. The list elements will therefore need to know that they are holding products (so look in the products table), and will need the product ID.

Some of the things lists will be storing will have non-numeric identifiers.

So, should I put my id/type pair in the list element, or should I create a new table that creates a surrogate key for the id/type pair as a simple int and use that...?

The surrogate key will take an extra lookup/join to get the key pair, but I won't need to mash two columns into my list elements table.

我需要为 Oracle 存储过程中使用的一些中间表创建代理标识键。我发现插入到 UROWID 列中的 ROWID 效果很好，但这在旧版本的 Oracle（10g 之前）中不是正确的方法——使用 SEQUENCE.NEXTVAL 是。SEQUENCE.NEXTVAL 是一个 2 步过程，会耗尽内存/存储（全表扫描），而使用 ROWID 方式，您只需保存地址即可。（如 SQL 中的 IDENTITY）
我想使用 ROWID 作为身份密钥。我可以这样做吗？

（抱歉英语不好）

假设我有模型 A、B、C。每个模型都有一个地址。

在“SQL 反模式：避免数据库编程的陷阱”（第 7 章 - 多态关联）一书中，有一个方法可以通过使用“通用超级表”（也称为基表或祖先表）来避免这种关联。

在多态上，它将是：

我知道您可以使用交集表，但以下解决方案看起来更精致：

配方建议创建一个只有一个 id 字段（代理键或伪键）的超级表（寻址），而不是多态地将 A、B、C 与地址相关联。然后，其他表引用寻址。这样，作者说，“您可以依靠外键强制执行数据库的数据完整性”。所以，它会是：

SQL 查询将如下所示：

问题是：如何在 Rails 中编写这样的场景？我尝试了几种方法都没有成功。

我正在尝试在 MySQL 中设计一个电子商务 Web 应用程序，但在为用户表选择正确的主键时遇到问题。给出的示例只是用于说明的示例。

用户表有以下定义

我在主键候选列方面面临以下问题：

标识列

优点

• 无业务意义（稳定主键）
• 更快的表连接
• 紧缩指数

缺点

• 不是“自然”键
• 所有属性表必须与“主”用户表连接，因此无法进行非连接直接查询
• 导致较少“自然”的 SQL 查询
• 泄漏信息：如果起始值为 0，则用户可以计算出注册用户的数量（更改起始值对此进行排序）ii）用户在 time_X 将配置文件注册为 user_A，稍后在 time_Y 注册为 user_B 将很容易计算一段时间内的注册用户数（（用户 B 的 ID）-（用户 A 的 ID）/（时间_Y-时间_X））

电子邮件栏

优点

• 没有任何

缺点

• 用户应该能够更改电子邮件地址。不适合主键

用户名列

优点

• “自然”主键
• 更少的表连接
• 更简单、更“自然”的查询

缺点

• 连接表时 varchar 列速度较慢
• varchar 列上的索引不如 int 列索引紧凑
• 很难更改用户名，因为外键取决于值。解决方案：“同步”应用程序上的所有外键或不允许用户更改用户名，例如，用户应删除配置文件并注册新的

external_customer 列

优点

• 可以用作客户的外部参考并且不包含任何信息（也许可以使用不可编辑的用户名？）

  缺点

• 如果它是自动增量的（如果可能），可能会泄漏信息

• 如果自动增量代理 id 已在使用中，则生成 unqiue 值是有问题的，因为 MySQL innodb 引擎在同一个表中没有多个 auto_increment 列

为可扩展的电子商务 Web 应用程序选择用户表主键时的常见做法是什么？所有反馈表示赞赏

有没有办法生成一个唯一的代理字符串，如 UUID.randomUUID() 但只包含字符（意味着没有数字）？该字符串存储在不同主机上的多个数据库中，并且必须在系统范围内是唯一的（即使我同时生成两个密钥 - 即通过线程）。

我已经阅读了许多关于自然主键与代理主键之间之争的文章。我同意使用代理键来识别其内容由用户创建的表的记录。

但是在支持表的情况下我应该使用什么？

例如，在假设的表“orderStates”中。此表中的值不可编辑（用户不能插入、修改或删除此值）。

如果使用自然键将有以下数据：

如果我使用代理键将有以下数据：

现在让我们举个例子：用户输入一个新订单。

在使用自然键的情况下，在代码中我可以这样写：

每次我有一个额外的步骤时，都使用代理键。

每次我必须将订单移动到新状态时，都会发生同样的情况。

那么，在这种情况下，选择一种密钥类型而不是另一种的原因是什么？

我试图了解规范化的确切工作原理并将其应用于我拥有的某些特定项目中。我在几个视频中看到第一步是定义一个候选键。

我想问，如果我拥有的所有字段（或这些字段的组合）都不是唯一的，会发生什么？例如，我有一个名为 Receiver 的字段。但我知道它是重复的。我想将它与名为 Time_Of_Week 的字段结合起来，但该字段也每周重复一次。最后我想将它与字段 Week_Number 结合起来，但这个字段也每年重复一次。

是定义自动增量主键的唯一解决方案吗？

谢谢 d.

我们有一个包含四个维度表和一个事实表的数据仓库设计：

• dimUser id、电子邮件、名字、姓氏
• dimAddress id, 城市
• dimLanguage id，语言
• dimDate id、startDate、endDate
• factStatistic id、dimUserId、dimAddressId、dimLanguageId、dimDate、loginCount、pageCalledCount

我们的问题是：我们要构建包括计算统计信息（取决于 userId、日期范围）和填充外键的事实表。

但是我们不知道如何，因为我们不了解如何使用自然键（根据我们阅读的文献，这似乎是我们问题的解决方案）。

我相信一个自然键是 userId，它在所有计算维度数据的 ETL 作业中都是必需的。

但是有很多困难：

• 在 ETL 作业 load() 中，我们使用 INSERT IGNORE INTO 进行批量插入以删除重复项 => 我们不知道生成的代理键
• 如果我们创建元数据（包括一组维度名称、代理键、自然键），由于重复消除，这将不起作用

问题似乎是重复消除策略。有更好的方法吗？

我们使用的是 MySQL 5.1，如果它有什么不同的话。