【发布时间】:2013-11-14 18:55:06
【问题描述】:
我刚刚开始了一个新项目,我遇到了一个只有 3 个外键约束的生产应用程序 Oracle 10g 数据库。我不习惯看到没有外键约束的数据库。我猜测不使用 FK 可能有一些性能/并发性考虑。原因是架构师在逻辑数据库模式中指定了所有关系,但这些关系并未在数据库中实现为外键约束。
问题:我读到我可以使用 RELY NOVALIDATE 定义一个不会影响性能的外键约束。是否值得在此数据库上定义 RELY FK 约束,以便可以轻松查看关系?这个应用程序不是使用 ORM 构建的,没有外键真的值得吗?
通过下面的示例对数据库进行非规范化
表 1 : FINProduct(ID (number), Description(varchar(5)), FINproductCode(varchar(10))...)
表 2:FINProductCode(ID (number, FINproductCode(varchar(10)) , LastUpdated(datetime)...)
因此,表 1 和表 2 之间没有关系,FINproductCode 列只是在表 1 中复制。
现在喝太早了,但我想我需要一个!
【问题讨论】:
-
没有与 FK 相关的性能损失。或者换句话说,它们是如此之小,以至于获得的数据完整性更有价值。因此,如果可能,请尝试添加 FK。在此过程中,您可能会发现一些数据指向不存在的父行。这需要解决。可能是从 MySQL 移植的数据 DB 在其中一个引擎中不支持 FK。 dev.mysql.com/doc/refman/5.5/en/ansi-diff-foreign-keys.html "对于 InnoDB 以外的存储引擎,MySQL Server 解析 CREATE TABLE 语句中的 FOREIGN KEY 语法,但不使用或存储它。"
-
在某些情况下,FK 的性能损失是不值得的——主要是在数据仓库环境中,通过完全控制加载过程来确保数据完整性。但是,在 OLTP 数据库中,您确实应该为每个“逻辑”外键关系添加一个“物理”外键约束。
-
@Frank Schmitt:是的,你是对的。在执行大量 INSERTS 和 UPDATES FK 时,可能会出现性能问题。
-
据我了解,这个应用程序是一个 OLTP 数据库,而不是数据集市/仓库。在我从震惊中恢复过来后,我意识到这个数据库严重非规范化,因此缺少 FK。对于 OLTP 类型的应用程序进行这种程度的非规范化真的有用吗?此 OLTP 主要用于金融交易
标签: oracle foreign-key-relationship