存储记录元数据的最佳实践

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

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

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

   优点：

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

   缺点：

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

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

   优点：

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

   缺点：

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

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

   优点：

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

   缺点：

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

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

您正在讨论的列占用20个字节（如果对齐时不带填充）：

创建时间，更新时间和创建源

时间戳.. 8字节
时间戳.. 8字节
整数.. 4字节

仅在单独表中的单独行的元组标头和项目指针将占用23 +1 + 4 = 28字节加上20字节的实际数据，再加上4字节的末尾填充。使得每行52个字节。在这里阅读更多：

• 配置PostgreSQL以获得读取性能

关于存储，您一无所获。关于性能，几乎不会丢失任何内容，每行仅增加16-24个字节。

列也直接属于行，因此将它们保持在一起是有意义的。我习惯将这样的列（为上次更新添加单独的源）添加到所有相关表中。

编写a TRIGGER ON INSERT OR UPDATE使其保持最新状态也更加容易。

长话短说：强烈支持您的选择1。

选项3的去向：
如果元数据经常更新，而核心行则不更新。然后，可能需要保留一个单独的1：1表以使UPDATE便宜并减少主表上的膨胀-甚至选择选项2。

选项2的去向：
如果元数据列的集合是高度重复的。您可能在主表中的元数据集中有一个FK列。像您的示例一样，对于三个小列并没有节省太多。