数据库设计，创建/修改/删除申请表

Question

我在Web应用程序，它取代纸质表格申请的课程创建/修改/删除工作，我需要帮助的最好的数据库设计实践，用于存储要求项目。

注意

• 数据库仅仅是请求的数据。一旦请求获得批准，数据必须手动输入到不同的系统中。 （我们在此没有控制）

• 它得到批准之前，申请可能被修改多次，我们需要每个请求

• 我们需要跟踪状态为每个请求

• 的修订历史记录

  有30多个问题，以创建（有多少项目需要修改依赖）课程

• 有3-30 +问题，修改课程

• 有5个问题，删除课程

我的方法1

在这种方法中，我会存储所有数据，创建/修改/在RequestDetail表中删除。由于每个RequestDetail可以有多个项目，例如CourseMode（例如在线，面 - 面），有与每个相关联的RequestDetail一些表。

下表是一个例子： 当用户请求创建课程（RequestID:1），有两个版本（标题和费用变化），直到它被批准。但对于修改及删除所有列NULL。

当用户请求修改CourseFee（RequestID:2）时，用户输入新的费用和修改原因，创建和删除的其余列为NULL。

当用户请求删除课程时（RequestID:3），用户输入删除的原因，其余列为NULL。

由于这些数据的目的，更像是一个数据仓库，这会是简单，易于处理？但表需要允许几乎所有领域空值（用于创建，大多数领域都需要）。

我的方法2

在这种方法中，要求修改的处理方式与第一种方法一样，但创建修订和删除单独的表。但是这种方法看起来多余而且不干净。

个人而言，我更喜欢第一种方法，但什么是最好的数据库设计实践是在这种情况下？有什么我忽略了，或者我需要小心吗？

Answer 1

听起来对我来说修改可以改变课程的任何内容，所以如果你有单独的CreateRequest和ReviseRequest表，几乎每一列都必须重复。我没有看到有任何理由这么做。

因为大部分数据都是不相关的，所以删除可能会有更多的争议。尽管如此，我还是没有看到为此制作单独的桌子所获得的任何收益。那么如果不相关的字段是空的呢？所以它有一堆空值。

其实我不会为“修改原因”和“删除原因”创建单独的列。我只是做一列，并称之为“请求原因”或其他。

你应该有一些字段告诉你它是哪种类型的请求。 （或者是FormTypeID是什么？）