1

这是问题的简化版本。

我们有客户向我们发送大量数据，然后进行查询。他们要求我们有几个“公共”ID，他们可以用来查询我们的数据。（大多数人希望通过他们与数据一起发送的 id 来查询我们的系统，但并非总是如此）。为简单起见，我们称它们为“pid”、“crid”和“musicbrainzid”。我们有一个“实体”表来存储这些信息。它看起来像这样（“权威”是发送数据的人）：

entity 
-- 
entity_id   
authority  // who sent the data
type       // 'pid', 'crid', 'musicbrainz', etc.
value      // the actual id value

然后我们有单独的实体，例如“episode”、“series”和“broadcast”（实际上，还有很多，但我在这里保持简单）。其中每一个都有一个指向实体表的 entity_id。

外部客户如何通过 pid 或 crid 搜索并获得适当的剧集或系列，以及正确识别它是什么？给定一个 pid，我们可以获取实体 id，但是我们需要在剧集、系列和广播表中搜索该值。此外，并非所有 id 都必然与所有其他表相关，但任何实体（例如，“episode”）都可能具有多个 id（pid、crid 等）

策略：

  1. 查找 pid 的实体 id 并在每个其他表中搜索该 pid。
  2. 在实体上放置一个“entity_type”列，但如果它是剧集表中的 pid，但我们不小心将剧集.type 设置为系列怎么办？我们不想复制数据，也不想将数据库元数据放入列值中。

选项 1 很慢而且似乎是错误的（此外，各种表的结构不同，这会造成问题）。

选项 2 表示重复数据，并且此数据可能不同步。我们可以使用触发器来强制执行此操作，但这看起来非常讨厌，而且无论如何，mysql 触发器实现中的错误已经多次袭击我们。我们现在正在使用这种策略，但没有触发器。

选项3是什么？

旁注：我们知道我们需要将“权限”分解到一个单独的表中，因为并非所有权限/类型组合都是有效的。

4

1 回答 1

3

如果我正确理解了您的问题，我会选择选项 1。

基于 entity_id 标识行的查询不应该那么慢，因为所有数据都应该在索引中。
如果您的索引配置正确，这甚至不应该访问实际数据。（至少在 SQL Server 中不会。）

我要做的一个小改变是创建一小组表来标识哪些 id 对哪些表有效。
然后，您将使用它来缩小需要搜索的表的范围。

选项 1 或 2 的替代方案可能是完全更改您的数据库结构，将不同的数据存储在同一个表上，使用 entity_id 作为主键，并使用包含数据的通用列。
这肯定会更加激进，但我已经看到它适用于像您这样的数据及其结构非常动态的系统。

于 2008-10-21T12:49:12.917 回答