使用 SQL，设计行为类似于其他表接口的表的最佳实践是什么？

Question

对于过去一年中遇到过几次的情况，我正在尝试找出最佳做法。

为了说明我设计了一个由用户、电影和用户观看的电影组成的虚假数据库。

在此示例中，我们希望能够捕获有关用户观看电影的任何时间的元数据，例如他们的位置或他们使用的设备，但我们将来可能希望收集的元数据类型可能会增长。目标是设计一个数据库，可以为一种电影观看体验聚合多种类型的元数据。

因此，我创建了一个名为 MovieWatchedMetaData 的表，以充当包含元数据的不同表之间的桥梁。前提是该表会将 LocationWatched 等元数据表中的主键链接到特定的电影观看场合。

我不确定这种方法是否会从长远来看有害。这是一个糟糕的做法吗？有没有更好、更合适的方法来实现这一点？您将如何组织这些表格？

Answer 1

评论太长了，所以我正在回答。我现在正在打字，但如果今晚我有时间，我会回来给你一个 ERD，让你更了解它。

一个表或一组表的接口几乎总是应该只是一个视图。话虽如此，我看到了一些选择：

1. 创建一个主元数据表，其中包含电影场合 ID，然后为您要链接到的每种类型的元数据创建一个 ID。您可以像当前一样将这些其他类型的元数据保存在它们自己的表中。当您想要跟踪其他数据时，您需要在主元数据跟踪器表中添加一列。

2. 查看您的元数据，这些元数据只是链接到电影场景的键/值对，并且只是有一个视图来旋转该表，因此键变成列，值变成这些列中的行。只要您不介意在想要添加不同类型的元数据进行跟踪时更新视图以容纳额外的列，这将为您提供带有任意元数据的电影体验的动态界面。如果您不介意在过程而不是视图中检索结果，您实际上可以使用动态 sql 根据所选电影出现的键/值对来确定应该存在哪些元数据列，并构建/执行您的数据透视查询当您想要添加列时，无需重新编译视图。

3. 为什么需要将每条元数据作为自己的列？如果您可以为您的元数据派生一个通用结构（可能是名称、描述、可为空的时间戳、值和电影体验 ID），那么您最终会得到一堆链接到每个电影体验的元数据行，有点像您会想象一篇博客文章可能有多个链接到它的标签，但在我们的例子中，标签实际上是一个具有多个字段的对象。

Answer 2

您必须考虑的是向查看数据添加新方面的“咕噜声”因素和恢复数据的“咕噜声”因素。没有一种解决方案（据我所知）可以解决它，因此您永远不必修改查询。 （不过，请考虑在 PostgreSQL 中探索 OO SQL 表达式。）

1. 它可以作为一个字段添加到 VIEWING（这是您的 MoviesWatched 表）中。例如，查看开始时间可能很适合查看表。这适用于不太可能改变结构的事物。
2. 可以将其添加为带有外键的表格以进行查看。例如，ViewingLocation 表有一组坐标。这与查看具有 1:1 的关系，并且可以说可以进入查看表。但是，今天您可以将它们记录为 GPS 坐标。明天您可能想要添加海拔高度或指向某个国家/地区的链接。
3. 它可以作为标准项目列表的链接添加，就像我对设备所做的那样。设备可能只列出一个简单的通用设备以及您要跟踪的有关该设备的所有信息。然后，多对多连接将其作为查看的 DeviceUsage（或 DeviceUsed）连接到查看。这适用于您想要反复引用的标准内容。

请注意，Viewer 和 Movie 也是 Viewing 的真正元数据。它们只是一种特殊情况，因为它们总是只有一个。 （如果您想在每次观看时记录多个观看者怎么办。在我的图表中，观看是一个人观看一部电影的事件。两个人同时观看同一部电影将是两次观看。）

所以，我可能会创建一个数据库视图，将所有内容挂起查看，以便检索和聚合任何元数据。我会将未来的元数据添加到每次查看中，具体取决于它如何符合上述 3 个标准之一。随着新元数据的添加，我会修改我的数据库视图。

正如我的导师曾经说过的，“这是一种方式。”我怀疑这种方式有问题，具体取决于环境。我完全期望被点燃。 :-) 希望看到其他解决方案——尤其是来自熟悉 OO-SQL 的人。