您总是在杀手级应用程序中使用的数据库表/字段[关闭]答案

【问题标题】：Database tables / fields you always use in your killer apps [closed]您总是在杀手级应用程序中使用的数据库表/字段[关闭]
【发布时间】：2009-01-20 15:38:51
【问题描述】：

我希望在这里利用一些集体经验，所以您的数据库设计中总是包含哪些（如果有）实用程序表或常用字段？

一个例子是我总是包含一个App_Errors 表来存储任何未捕获的异常信息，以及一个App_Audit 表来存储所有编辑信息。

我已经（在我自己的脑海中）提出了在每个数据表中包含 RecordCreatedDate 和 RecordLastEditedDate 的好处，但对于这些信息是否真的有用，我没有得出任何结论。

给这个问题更多的方向 - 我目前的重点是全球可访问的网络应用程序（想想社交网络）。

塔！

【问题讨论】：

标签： database-design web-applications

【解决方案1】：

1 包含版本号的表，因此应用可以轻松检查架构的版本。

2 保存任意变量/值对的表，如配置文件，但在数据库中。（你可以把版本号放在这里....）

【讨论】：

第 2 点 +1。我倾向于称其为“属性”。第 1 点也是有效的。
我要补充一点，任意 var/val 表作为 category/var/val 表效果更好。
我有一个名为“schema_version”的表。每次数据库升级都会插入到该表中，包括版本号、描述和系统日期。

【解决方案2】：

我经常使用审核日志表来跟踪更改了哪些数据以及由谁更改。

您会惊讶于它经常带来巨大的好处。

在我处理的几乎每个数据模型中都会出现的其他问题是状态表的变体，通常与主要实体的状态生命周期有关。

【讨论】：

您在审核日志中实际放入了什么？应用生成的 cmets、SQL 查询还是什么？
@Draemon - 对于我工作过的大多数系统，只要简单记录一下谁更改了记录就足够了 - 其他要求记录更改前的数据，以及其他已要求记录涉及的核心 SQL 语句。

【解决方案3】：

每个表，不管它做什么，总是以一个“ID”字段开头，int。

我还保存了一个错误表，其中包括 ID、日期时间、失败的方法和重载，以及堆栈跟踪（如果有）。

有时我有一个设置/统计表，但并非总是如此。

【讨论】：

【解决方案4】：

对于报告，一个数字表（从 0 到 1Mil 的整数）和一个静态日期表（相当于 30 年的天数）。

【讨论】：

我会重复上面的问题，为什么是数字表？还有静态日期表的用途是什么 - 鉴于大多数编程语言和报告系统都提供了许多日期功能......
一种用途：用于报告差距 - 例如。 "列出过去 100 天内未收到订单的日期"。
@Tony - 正是我所需要的。拥有数字/日期表允许基于集合的检索，并避免在应用层中使用游标或重复查询逻辑。
见stackoverflow.com/questions/418318/…

【解决方案5】：

包含错误代码、技术消息、用户消息、严重性和备注列的错误消息表。严重性和用户消息用于在发生错误时构建消息对话框。记录错误时，错误代码和技术消息包含在错误日志中（连同客户端的 IP、日期、时间等）。

【讨论】：

【解决方案6】：

我倾向于总是有一个表格列出所有可以访问系统的用户。出于连接池的原因，我更喜欢这样做而不是为每个人创建单独的数据库用户。

然后通常会有一个表格列出人们在系统中可以拥有的角色。连接表指示允许谁做什么。这种设置通常会因业务领域中特定于应用程序的规则而变得更加复杂。

审计表是一个非常好的主意。我包含一个人类可读的列，以便非技术人员有机会了解发生了什么，以及存储各种键和重要值。

【讨论】：

【解决方案7】：

我发现包含以下字段总是很方便：

不活动（或可见/停止/等）
非活动原因

让“软删除”项目变得非常容易，从而保持数据完整性，并且不会丢失宝贵的历史信息。

Galwegian 提到的审核日志表 +1。

【讨论】：

【解决方案8】：

成员资格表。无价之宝。

【讨论】：

【解决方案9】：

任何保存用户数据（与您的系统数据相反）的表都有创建日期和最后更新日期。如果有 1% 的机会，您可能需要知道某事何时发生。这将在未来省去很多麻烦。虽然我不喜欢触发器，但使用它们来维护这两个字段是值得的。如果您使用真实的数据库登录，那么 created_user 和 updated_user 也很有用。

【讨论】：