如今，我正在研究一个没有“关系，PK和FK”的数据库 原始数据。 我可以说数据库只是一组文件。 当我问起这件事时，我有这个; “隐藏业务”。
另外，我的一位朋友说，这总是发生在“大型系统”中。
在大型系统中，他们通过原始数据来隐藏业务。 关于发展;关系，约束，验证，使用触发器，当然还有用户界面在数据库中完成。
您对此有何看法？
答案 0 :(得分：3)
嗯，当你需要快速响应大量 DML时，可能指向大型数据库（{{1 }}）。
问题在于，如果您依靠数据库的方式来确保完整性，那么您很难对其进行优化。
INSERT / UPDATE / DELETE中还有一个名为SQL/PLSQL context switching的内容：如果您在桌面上创建一个空触发器，它会减慢Oracle约20倍的速度 - 只有触发器存在的事实。
在Oracle中，当您在表中编写DML触发器并更新ON UPDATE行时，触发器和其中的查询将被调用50,000次。外键执行得更好，但它们也可能变得迟钝（并且您无法对基础查询执行任何操作）
在这种情况下，最好将要更新的结果放入临时表，发出50,000，检查前后的完整性，并应用业务规则。处理MERGE行的单个查询比处理单行的50,000查询循环工作得更快。
当然，实施起来非常困难，只有当你拥有真正的大型数据库且需要对其进行真正的大量更新时才能收回成本。
在50,000中，无论如何，Oracle约束比实现相同功能的跳跳器执行得更好。
FOREING KEY很可能会提高性能，因为主键意味着在约束字段上创建PRIMARY KEYS，并且可以在查询中有效地使用此索引。 UNIQUE INDEX也是一种强制唯一性的自然而有效的方法。
但是，当然，正如任何索引一样，UNIQUE INDEX以及那些INSERTS条件不具有选择性的UPDATES和DELETES会慢下来。
予。即如果您需要WHERE或UPDATE DELETE行1，那么索引就是您的朋友;如果您需要2,000,000或UPDATE DELETE行1,500,000，则索引是您的敌人。这是一个权衡问题。
您可能还会看到我的回答here。
答案 1 :(得分：2)
我认为通过默默无闻来牺牲数据完整性是一项糟糕的交易。
答案 2 :(得分：2)
我想我至少遇到过两个缺少关系和FK的数据库的应用程序。
这个想法可能是对 brillant 数据库架构进行逆向工程更加困难。
副作用是应用程序通常不太擅长检查约束本身，导致数据库中的大量垃圾数据，实际上确实使反向工程变得更加困难，因为不强制执行FK约束;）
我的观点是，一旦它是一个数据库，其他人就可以调查它，并且试图解决这个可见性的“特征”是没有意义的，并且通常不是一件好事，考虑到缺点（没有关系，没有SP，没有触发器等）。
答案 3 :(得分：0)
主键，关系等是使数据库开发更容易并使最终结果更快更有效的工具。我只能想到一些罕见的案例，其中没有关键/索引是个好主意。
您的朋友解释了为什么他们持这种观点？
答案 4 :(得分：0)
这种事情可能发生在金融系统中。这与你所期望的相反，你会认为，因为它的财务状况会更严格地应用最佳实践。然而，反过来通常是正确的。其中许多数据库可能都是以excel开头的。
我见过很多数据库，他们不打扰fks或pks。我不能说我喜欢它，但有时你必须要忍受它，或者离开并去其他地方以更少的钱工作，但数据库的完整性更高。
也许这就是他们需要你的原因。
答案 5 :(得分：0)
（我= MSSQL）
从包含大量FK的大型表中删除行的速度很慢。
我们的APP从未被拒绝删除该表上的FK约束违规
我考虑放弃FK以提高性能。
虽然实际上已经做过鸡了:(
PS我们会将FK保留在DEV / TEST系统上
答案 6 :(得分：0)
这可能是从以前使用基于文件的结构来保存数据的系统转换而来的。新数据库中的表只是各个文件的反映。