mysql - 使用 SQL,设计行为类似于其他表接口(interface)的表的最佳实践是什么?

标签 mysql sql database postgresql database-design

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

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

enter image description here

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

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

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

最佳答案

这篇评论太长了,所以我改为回答。我现在正在忙着打字,但如果我今晚有时间,我会回来讨论这个问题并给你一个 ERD 以更好地理解它。

一个表或一组表的接口(interface)应该几乎总是一个 View 。话虽如此,我看到了几个选项:

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

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

  3. 为什么需要将每条元数据作为其自己的列?如果您可以为您的元数据推导出一个通用结构(可能是名称、描述、可为空的时间戳、值和电影体验 ID),那么您最终会得到一堆链接到每个电影体验的元数据行,就像您希望的那样想象一篇博文可能有多个链接到它的标签,但在我们的例子中,一个标签实际上是一个具有多个字段的对象。

关于mysql - 使用 SQL,设计行为类似于其他表接口(interface)的表的最佳实践是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38860345/

相关文章:

mysql - MySQL 中的两步左连接

java - j2me数据库查询包括条件

ios - 是否可以创建自定义核心数据持久存储协调器?

database - Neo4j 的引用完整性

sql - MYSQL多表join前N行

mysql - 设计每个用户都有收藏夹列表的数据库

MySQL,排序 GROUP BY

mysql - 无法从表单 zend 2 插入数据

php - 制作无限子类别的最佳方法是什么

sql - 有没有一种干净的方法来清理 MySQL 中的重复条目?