相关疑难解决方法(0)

我在这里读到了关于5NF,EAV和6NF的讨论,以及需要一个目录来"自动"处理元数据和复杂的SQL.这是如何在实践中实施的？

PerformanceDBA在提到目录的6NF和EAV上写了几个答案,例如在以下问题中:

• 想用一个例子来理解6NF

• 6NF和历史属性数据

• 特别是多个固定表与灵活的抽象表,PerformanceDBA写的

  "例如,对于6NF数据库与目录,我有一组特效,将[重新]产生执行所有根据需要选择SQL,我提供5NF为所有用户意见,所以他们不需要知道或了解的基础6NF结构.它们被驱逐出目录.因此变化很容易并且自动化.由于缺少目录,EAV类型手动完成."

这个问题与我在其他问题中可以找到的架构有关. 基本上在我的数据库中,我存储用户,位置,传感器等.所有这些都可以由用户在系统中编辑,并且可以删除.

但是 - 当编辑或删除项目时,我需要存储旧数据; 我需要能够在变更之前看到数据是什么.

数据库中还有不可编辑的项目,例如"读数".他们真的更像是一个日志.读数记录在传感器上,因为它是特定传感器的读数.

如果我生成一个读数报告,我需要能够看到读取时位置或传感器的属性.

基本上我应该能够重建任何时间点的数据.

现在,我之前已经完成了这项工作,并通过在每个可编辑表中添加以下列来使其运行良好:

valid_from
valid_to
edited_by

如果valid_to = 9999-12-31 23:59:59则那是当前记录.如果valid_to等于valid_from,则删除记录.

但是,我对我需要用来强制执行外键一致性的触发器感到满意.

我可以通过使用"PostgreSQL"数据库的扩展来避免触发器.这提供了一个名为"period"的列类型,它允许您存储两个日期之间的一段时间,然后允许您执行CHECK约束以防止重叠周期.这可能是一个答案.

我想知道是否有另一种方式.

我见过人们提到使用特殊的历史表,但我真的不喜欢几乎每1个表维护2个表的想法(尽管它仍然可能).

也许我可以砍掉我的初步实施,以不打扰检查不属于"当前"记录的一致性 - 即只懒得去查制约记录中,其中的失效日期9999-12-31 23:59:59.毕竟,使用历史表的人似乎没有对这些表进行约束检查(出于同样的原因,你需要触发器).

有没有人对此有任何想法？

PS - 标题还提到了可审计的数据库.在我之前提到的系统中,总是有edited_by字段.这允许跟踪所有更改,以便我们始终可以看到谁更改了记录.不确定可能会有多大差异.

谢谢.