设计数据库表的最佳实践是什么答案

【问题标题】：What are the best practices for designing DB Tables设计数据库表的最佳实践是什么
【发布时间】：2017-02-17 02:15:19
【问题描述】：

我们正在构建我们的数据库设计（使用 PostgreSQL）并且对于（几乎）每个表，我都有以下列

CREATE_TIMESTAMP TIMESTAMP,
CREATED_BY       VARCHAR(25),
modified_TIMESTAMP TIMESTAMP,
modified_BY       VARCHAR(25),

我还在为一些实体表使用审计表。截至目前，数据库大约有 15 个表（很快将增长到大约 50 个）。对于大约 20% 的这些表（它们是实体），我们需要将它们（使用触发器）备份到审计表的相同副本。例如：一个家庭有 1 个或多个“联系人”。一个联系人有电子邮件、电话等信息加上 1 个“地址”。因此，当族被创建、修改或删除时，我使用触发器将族表的内容复制到其 AUDIT 表 Family_Audit。同样，当对“Contact”表进行更改时，我会将其复制到 Contact_Audit 表中。地址也一样。

变更日志表：如果我已经为每个需要“审核”的实体表提供了审核表，那么拥有变更日志表的意义何在？

鉴于此，我想知道使用上述“样板”列对我来说是否仍然有意义。

有没有cmets？

更重要的是，您添加到（几乎）每个 Table 的样板列是什么？为什么？

【问题讨论】：

PostgreSQL 跟这个问题有什么关系？这个问题不是适用于所有数据库吗？ PostgreSQL 有什么特别之处？
S.Lott ：是的，它是通用的。我只是想让成员知道我专门使用 postgreSQL，如果他们想添加与此相关的任何内容，我很好。
“是的，它是通用的”。然而，PostgreSQL 说。您能否更改问题以明确这一点？ PostgreSQL 不是中心，它只是一个例子。什么的。
Why do we need Audit Columns in Database Tables? 的可能重复项

标签： postgresql database-design

【解决方案1】：

我尽量避免使用“样板列”。

如果您想要更改日志，请创建一个ChangeLog 表，其中用户名、时间戳、表名和表行 ID 在日志中，而不是在表上。

唯一接近“样板”的是代理主键（称为 ID）。

在大多数情况下，“样板”——更改历史——甚至都不是问题，因为我尝试创建保留历史的设计。我尝试将 UPDATE 的发生率降至最低。

数据可以很容易地保存——完整地——与“当前”记录和该记录的所有先前版本一起保存。现在磁盘很便宜。用户更新的历史日志似乎效果更好。撤消用户更改很简单，因为以前的版本都可用。

我不再在“样板列”中看到任何值

如果未保存实际内容（在其他列中），如何在日志中存储“表行 ID”？

什么？ 可以保存行之前的值。这才是重点。您有多种保留历史记录的方法。

将历史记录表与之前的值分开。
一个“标志”——创建一个由两部分组成的密钥——具有“当前”与“历史”设置。
可能使用“活动日期”和“活动日期”对。

还有其他技术。阅读有关渐变维度 (SCD) 算法的信息。

这些技术中的每一种都有独特的要求；它们是设计模式，而不是样板。

【讨论】：

嗨 S.Lott，在考虑了您的意见后，我有一个问题。 “如果要更改日志，请创建一个 ChangeLog 表，其中用户名、时间戳、表名和表行 ID 在日志中，而不是在表上。”假设我有一个表地址创建表地址（id bigint not null, line1 varchar(50), line2 varchar(50), city varchar(50), state varchar(50), zipcode varchar(10)）我将如何设计ChangeLog 表呢？我的意思是，如果未保存实际内容（在其他列中），将“表行 ID”存储在日志中有何帮助？谢谢，

【解决方案2】：

您说得对，在存在完整审计表的情况下，这些列在逻辑上是多余的。

如果您需要对以下查询进行简单的、基于索引的访问，那么保留其中任何一个的优势就会显现出来：

列出在特定日期范围内创建的记录（尽管这仍然可以很容易地从审计表中得到回答）。
列出特定人员上次更新的记录（不太容易优化此类查询）。
显示最近更新的 100 条记录（同样，在审计表上不太容易优化）。

我会不使用它们，只有在需要时才重新添加它们。您可以在那时从审计表中填充现有行的值。

【讨论】：