小编Tid*_*ddo的帖子

据我所知，许多 DBMS（例如 mysql、postgres、mssql）仅使用 fk 和 pk 组合来限制对数据的更改，但它们本身很少用于自动选择要连接的列（就像自然连接与名称一样）。这是为什么？如果你已经用 pk/fk 定义了 2 个表之间的关系，为什么数据库不能弄清楚如果我加入这些表我想在 pk/fk 列上加入它们？

编辑：澄清一下：

假设我有一个 table1 和一个 table2。table1 在 a 列上有一个外键，它引用 table2 上的主键，即 b 列。现在，如果我加入这些表，我将不得不做这样的事情：

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

但是，我已经使用我的键定义了 table1.a 引用 table2.b，所以在我看来，让 DBMS 系统自动使用 table1.a 和 table2.b 作为连接列应该不难，这样就可以简单地使用：

SELECT * FROM table1
AUTO JOIN table2

然而，许多 DBMS 似乎并没有实现这样的东西。

在数据库中存储单个记录的元数据的最佳实践是什么？

我需要在我的数据库中存储许多表的常见元数据，例如创建时间和上次更新时间。我找到了几种不同的解决方案：

1. 将元数据直接存储在表中。

   优点：

   • 元数据直接链接到记录
   • 无需连接即可检索元数据

   缺点：

   • 需要大量重复列（除非使用继承）
   • 元数据和业务数据不分离

2. 创建一个通用元数据表，并使用软外键将数据链接到正确的表和记录。

   优点：

   • 没有重复的列
   • 元数据与业务数据分离

   缺点：

   • 元数据和数据之间没有直接链接（不能使用 FK）
   • 联接需要附加条件

3. 为每个需要元数据的表创建单独的元数据表。

   优点：

   • 元数据直接链接到记录
   • 元数据与业务数据分离

   缺点：

   • 需要很多额外的表
   • 需要大量重复列（除非使用继承）

是否有比我在这里提到的更多的选择、优点或缺点？存储这些元数据的最佳实践是什么？

我在数据库中有一个消息表，其中包括发件人 ID 和消息类型（当然还有更多与此问题无关的列）。我尝试创建一个查询来计算用户发送的每种类型的消息数量。

例如，如果我有下表：

---------------------------
身份证 | 用户 ID | 消息类型
---------------------------
1 | 1 | 私人的
2 | 1 | 民众
3 | 1 | 私人的
---------------------------

然后我想得到以下内容：

---------------------
身份证 | 私人 | 民众
---------------------
1 | 2 | 1
---------------------

所以实际上我想按 message_type 和 user_id 分组，但不是为每个用户生成多行，我想创建多个列，每个 message_type 一个

我可以在不对查询中的消息类型进行硬编码的情况下实现这一点吗？