SQL Server中的NoSQL

这个问题与SQL和NoSQL之间的区别无关。我正在寻找一些目前对我来说实际上毫无意义的理由（可能是由于我缺乏理解或欣赏）。

我们从头开始使用MVC5，Entity Framework 6代码和SQL Server 2008开始了一个新项目。当架构师检查数据库架构时，声明应该删除所有外键和其他此类约束，因为这是“业务逻辑”，并且应该在应用程序代码的业务层中应用。

我的观点是，外键构成数据/引用完整性的一部分，并不能真正模仿业务逻辑。我将业务逻辑视为控制引用什么/何时/如何/为什么应用引用的过程和验证。我可以理解唯一的约束可以说是业务流程，但是对我而言，这只是逻辑的补充，并构成完整性的一部分。

第二个论点是目标是对数据采用NoSQL方法。我发现这确实是不寻常且不合常规的：考虑到使用SQL Server 2008，报告的需要，数据无法扩展到TB级以及缺乏对诸如Mongo，Raven等技术的考虑。

有人遇到过这种情况吗？为什么有人在为参考数据设计的SQL Server中采用NoSQL方法而不想要外键？

当他查看数据库模式时，他说所有外键和其他此类约束都应删除，因为这是业务逻辑，应在业务层内应用。

那时他是个白痴，有一天您的代码库摘录可能会出现在The Daily WTF上。绝对正确的是，他的方法没有道理，坦率地说，他的解释也没有。

尝试向他解释引用完整性约束不是“业务逻辑”；它们是带有自身内置验证的正确性标准。 业务逻辑与您对数据的处理有关。完整性是关于确保数据本身没有损坏。如果那不起作用...很好，他负责。您可以按照他的计划并尝试减轻损失，或者开始寻找更好的工作场所。（或两者。）

我还没有创建外键的理由

- 乔尔·斯波斯基（Joel Spolsky）

除了一揽子声明，值得承认的是，有充分的理由选择不使用唯一性或外键约束。大多数人都这样：

• 性能。用原子事务进行完整性检查不是免费的。通常，数据库是架构扩展中最困难的部分。也许您已经在应用程序逻辑中进行了检查，而不希望增加性能。
• 缺乏需要。也许您的数据很脏，您还可以。这在很大程度上取决于您在做什么。

另请参见外键有什么问题？

但是，这些与您提出问题的原因不符。

这是业务逻辑，应在业务层中应用。

这个原因有点奇怪。唯一性和其他完整性约束在很大程度上是ACID数据库的领域。您的应用程序代码无法达到SQLServer的原子性和完整性保证。如果您需要强大的数据完整性，则忽略数据库是愚蠢的。

第二个论点是，他们希望对数据存储采用NoSQL方法，因此不希望有这样的限制。

第二个原因不是真的。这是一个结论。尽管约束是正确性与性能之间的折衷，但NoSQL数据库偏向后者。

也许您的系统架构师会想到这些合理的原因，而您却听错了。也许他是个白痴。

在任何情况下，都有充分的理由（尽管不是普遍的）理由避免使用唯一性和外键约束。

PS：如果得出结论，您不需要外键，则使用关系数据库仍然可以。一般而言，关系数据库比NoSQL对应数据库更成熟。作为单个节点，它们甚至可以更快，并且可以在它们之上构建 NoSQL抽象。