【问题标题】:Database design: Managing old and new data in database table数据库设计:管理数据库表中的新旧数据
【发布时间】:2017-02-15 02:29:42
【问题描述】:

我有一个表Student,字段如下,

学生表(每个学生一条记录)

student_id
Name 
Parent_Name
Address_line1, Address_line2, Addess_line
Photo_path
Signature_file_path
Preferred_examcity_choice1,Preferred_examcity_choice1, Preferred_examcity_choice3
Gender
Nationality
.
.
.

我正在通过网络界面在完成注册表单时插入此表。

现在 Web 界面中还有一个模块用于更新学生数据,在每次更新请求时,我都会更新 student 表记录并在 student_data_change_request 中插入新条目。学生可以多次更改记录。

student_data_change_request

request_id(auto_incr PK)
old_name
new_name
old_photo_path
new_photo_path
old_signature_file_path
new_signature_file_path

现在问题来了,早期的学生被允许更改很少的字段,现在客户希望允许候选人更新更多的字段(大约 20 个字段)并为相应的列添加 oldnew 列不是优雅和首选(我猜),我最终将创建 40 列来跟踪 20 列。那么我应该如何重新设计我的桌子呢?欢迎提出建议。

【问题讨论】:

    标签: mysql sql-server oracle postgresql database-design


    【解决方案1】:

    一种方法是创建一个名为 (table)_xx 的影子表,该表具有相同的列、时间、日期、更新/插入/删除标志、用户或其他任何内容,并且没有参照完整性。设置触发器以在发生任何事情时从源更新该表。

    如果您有真正的业务需求需要历史记录,那么请正确执行,但这种模式非常适合作为一般审计、调试和取证工具。

    自动化/脚本化也很容易,因为您只需从数据库元数据生成它。

    【讨论】:

    • +1 对于这个解决方案。此外,借助 Oracle 12c,闪回技术可以帮助您更轻松地实现这一目标。 docs.oracle.com/database/121/ADFNS/…
    • 是的,Oracle 闪回很棒,虽然没有得到普遍支持。 SQL Server 现在有一些选项,但据我所知,这还不够。
    【解决方案2】:

    通常历史表是这样的:

    request_id
    column_name
    old_value
    new_value
    dt
    

    request_idcolumn_name 是主键。当您更新 student 表时,您会在 student_data_change_request 中为每个更新列插入新条目。

    已编辑: 另一种方式:

    request_id
    value_type
    name
    photo_path
    signature_file_path
    ...
    

    并插入具有旧值的第一个条目和具有新值的第二个条目。列 value_type 标记为 oldnew

    【讨论】:

      【解决方案3】:

      我宁愿只有一个表格,另外还有一个用于显示生效日期的列。然后,只为每个 student_id 获取最新行的视图成为您的第一个“表”。如果由于某种原因您必须并排显示“当前”和“最近更改”的值,那是另一种视图。

      【讨论】:

      • 其实学生证是主键,一个学生不能有两条记录。
      【解决方案4】:

      像往常一样,这完全取决于您打算如何使用这些数据。

      在这些情况下,我的强烈偏好是@mathguy 建议的解决方案 - 在主表设计中嵌入时间概念。这让您可以问“这个学生在 1 月 1 日的地址是什么?”或“谁在 2 月 12 日有签名 x?”。

      如果您必须报告或执行反映任何时间点的状态的业务逻辑,那么这种设计非常有效。例如,如果您必须报告给定学期有多少学生住在特定地址,您想知道记录何时有效。

      但并非所有应用程序都关心“时间” - 有时,您只想拥有一个审计表,以便在出现异常时跟踪一段时间内发生的情况。

      在这种情况下,@loztinspace 的解决方案很有用 - 但根据我的经验,这会迅速升级为更多工作​​,因为想要检查审计记录的人可以或不应该访问您生产环境中的 SQL 提示符。

      【讨论】:

        猜你喜欢
        • 2013-09-25
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-08-21
        • 2012-02-10
        • 1970-01-01
        相关资源
        最近更新 更多