2015-02-24 73 views
1

我有一个名为Documents的表格,它存储文件的文件名,备注等。相关的字段有:触发器/用于数据完整性的存储过程器

  • Document_ID - 自动编号
  • Document_Type_ID - FK查找表Document_Types
  • Table_Unique_ID

Table_Unique_ID涉及到任何其他表中,我们使用了其他ID的知道其中表格由相关Document_Type_ID

E.g.

  • Document_Type_ID = 1涉及Projects表,所以一个文档与记录的1357一个Table_Unique_IDDocument_Type_ID 1意味着它涉及Project_ID = 1357

  • Document_Type_ID = 2涉及Sites表,所以一个文档记录用的1357和2 Document_Type_IDTable_Unique_ID装置1357的

等一个Site_ID

这允许什么类型的文档,我们任何表中的各种记录保持了极大的灵活性,ProjectsSitesContacts等而不是创建单独的表(Project_DocumentsSite_Documents等)。

它已经指出,数据的完整性是很难(甚至不可能)使用传统的简单的PK/FK关系强加,因为这1357可能涉及要么ProjectsSites

当前数据完整性由用户界面检查处理。

问题是,当插入Document记录或删除'其他'记录(Projects,Contacts等)时,触发器或存储过程是否有帮助?

如果是这样,我真的很感激被指出正确的方向。

+3

看似很大的灵活性 - 但从数据完整性的角度来看,这是一个**可怕的**设计。我不会浪费时间在调查触发器和东西 - **修复设计!** – 2015-02-24 15:09:06

+1

我同意@marc_s 100%。设计看起来很“酷”,但实际上它会变得痛苦而缓慢。 – 2015-02-24 15:11:33

+0

*目前数据完整性是由用户界面检查处理* - 这使我的胆量畏缩.....基本上,**数据完整性**在这种情况下不***处理.... – 2015-02-24 15:13:19

回答

-2

您的主要目标是什么?数据完整性,还是灵活性和干净的设计?这些是相互矛盾的利益。如果你绝对必须在没有触发器的情况下执行完整性,你将不得不有一个更丑陋的设计。必须始终在数据库设计中做出妥协。你会得到数据完整性的精英们对这种设计有多糟糕的问题感到不安,但是在一天结束时是否值得更正常化呢?

+0

在大多数严肃的商业应用中,数据完整性比“好”的设计重要得多......毕竟,数据是解决方案的基础。如果你有一个不错的设计,但是你的数据质量很糟糕 - 你很快就会倒闭。不要为像“新潮和新潮”设计这样的东西牺牲所有重要的**数据完整性 - 这些设计每月都会来来去去 - 数十年来您的数据将围绕(并对您的业务非常重要)。最好是**状态良好!** – 2015-02-24 15:46:30

相关问题