存储过程是全球最大的IT软件咨询公司之一的不良做法？

#1 楼

根据我从事大型项目的经验，您必须非常清楚业务逻辑的用途。如果您允许单个开发人员将业务逻辑放在他们认为合适的业务对象层或存储过程中的环境，那么大型应用程序将变得非常难以理解和维护。

存储过程很棒用于加快某些数据库操作。我的体系结构决定是将所有逻辑保留在应用程序的业务层中，并以有针对性的方式采用存储过程来提高性能，以进行基准测试表明必须这样做。

#2 楼

一些观察结果

存储过程为您提供代码重用，
和封装（
软件开发的两大支柱），

只有在正确使用它们的情况下应该使用它们的上下文。关于功能（在结构化编程中）或方法（在面向对象编程中）的说法可以相同，但是，我们看到1K函数和巨型对象。正确使用这些工件才有这些好处。

安全性（您可以为单个存储的proc授予/撤消权限），

是。这是一个好点，也是我喜欢存储过程的主要原因之一。与仅使用视图和用户帐户通常可以实现的访问控制相比，它们提供了更好的粒度访问控制。

保护您免受SQL注入攻击，因为您可以使用参数化的SQL语句和输入清理来达到相同级别的保护。但是，除了“ SP的深度安全性”之外，我还将使用SP。在Server 2008中，即使运行常规SQL查询也可以进行编译（足够的时间）。确实会编译SQL语句（静态或参数化）。如果您希望/需要聚合和计算您无法使用简单的SQL语句完成但与SQL紧密集成且不保证与应用程序服务器往返的数据，SP可以提供帮助。到一个临时游标（或多个游标）中，从中运行另一个SQL本身。您可以在应用服务器中以编程方式进行操作，也可以通过在数据库中进行操作来保存多次往返。
但是，这不应该成为常态。如果您遇到许多情况，则表明数据库设计不良（或者您正在从跨部门的不太兼容的数据库架构中提取数据。）

我们正在使用
敏捷软件开发
方法论。

敏捷性与软件工程流程和需求管理有关，与技术无关。

谁能想到好的
他们不想使用存储的
进程的原因？使用GOTO”？在这个问题上，我与尼克劳斯·沃斯（Niklaus Wirth）的支持远胜于迪克斯特拉（Dijkstra）。我可以理解Dijkstra的情绪来自何处，但我认为这并非在所有情况下均适用100％。与存储过程和任何技术相同。
工具可以很好地用于预期目的，并且是完成特定任务的最佳工具。否则使用它并不表示该工具是错误的，而是表示焊工不知道他/她在做什么。
正确的问题是“应避免使用哪种类型的存储过程使用模式”。或者，“在什么条件下我（或不应）使用存储过程”。寻找不使用技术的原因只是将责任归咎于工具，而不是将工程责任直接归于其所属的领域-在工程师中。
换句话说，这是一种应对或声明。无知。

我的猜测是DBA不想
维护那些存储的proc，但是
似乎有太多的否定理由不能证明这种理由。一种设计决策。 />我的经验是，在罗马时，就像罗马人一样。
不要打架如果您公司的员工希望将存储过程贴上标签，这是一种不良做法，请允许他们。但是，请注意，这可能是其工程实践中的一个危险信号。
通常，在一些有大量不称职的程序员的组织中，通常将其标记为不良实践。通过将某些事物列入黑名单，组织试图限制由于自身能力不足而在内部造成的损害。我不拉你。说存储过程（或任何类型的技术）是不好的做法，这是一种概括。概括是无能的解决方案。工程师不能进行公然的概括。他们会根据具体情况进行个案分析，权衡分析并根据手头的事实执行工程决策和解决方案。
优秀的工程师可以做到不要以这种笼统的方式将事情标记为不良做法。他们着眼于问题，选择合适的工具，进行权衡。换句话说，它们可以进行工程设计。可以在其中放入一些数据按摩逻辑，或者将多个查询的结果聚合在一起。就是这样。超出此范围的任何内容都可以视为应该驻留在其他地方的业务逻辑。


不要将它们用作防御SQL注入的唯一机制。您可以将它们留在这里，以防万一有坏事发生，但是在它们前面应该有一系列防御性逻辑-客户端验证/清理，服务器端验证/清理，可能转换成对您有意义的类型域模型，最后传递给参数化的语句（可以是参数化的SQL语句或参数化的存储过程。）


不要使数据库成为唯一包含存储过程的地方。您应该像对待C＃或Java源代码一样对待存储过程。也就是说，源代码控制商店过程的文本定义。人们对存储过程的抱怨不能由源控制-废话，他们只是不知道他们在说什么该死的地狱。


我对如何/在何处使用它们的看法


您的应用程序需要从多个查询或视图转置或聚合的数据。您可以将其从应用程序卸载到数据库中。在这里，您必须进行性能分析，因为a）数据库引擎在执行这些操作方面比应用服务器更高效，但是b）（有时）应用服务器在水平方向上更易于扩展。细粒度的访问控制。您不希望某些笨蛋在数据库中运行笛卡尔联接，但是您不能仅仅禁止人们像这样执行任何SQL语句。一种典型的解决方案是允许在开发和UAT环境中使用任意SQL语句，而在systest和生产环境中禁止使用它们。任何必须进入系统测试或生产的语句都会进入存储过程，由开发人员和dbas进行代码审查。经历不同的用户名/帐户和连接池（高度监视和劝阻使用）。在像Oracle这样的系统中，您可以访问LDAP或创建到外部数据库的符号链接（例如，通过vpn在业务合作伙伴的数据库上调用商店proc。）执行意大利面条式代码的简便方法，但这对所有编程范例都是正确的，并且有时您具有特定的业务/环境要求，这是唯一的解决方案。存储过程可帮助您轻松地在一个地方将这种麻烦封装在靠近数据的地方，而不必遍历应用服务器。

您是将它作为存储过程在数据库上运行还是在应用服务器上运行，这取决于您作为工程师必须进行的权衡分析。两种选择都必须进行分析，并通过某种类型的分析来证明其合理性。通过简单地指责另一种替代方法是“不好的做法”而走了一条路，这只是一个la脚的工程学解决方案。 （例如，没有用于新硬件或云实例的预算），但是在数据库后端具有足够的容量（这是很多人都愿意承认的典型），因此必须花钱将业务逻辑存储到proc中。不够漂亮，可能会导致贫乏的领域模型……但随后又要……进行权衡分析，这是大多数软件黑客所吸纳的东西。

这是否成为永久性解决方案，具体以限制在特定时刻观察到的问题。
希望有帮助。

#3 楼

其基本原理是，依赖于存储过程层会限制可移植性，并将您与某个数据库绑定。也有增加维护成本的原因。我还想对您提出的这一点发表评论：


（存储过程）保护您免受SQL注入攻击的侵害


可以保护您，您可以在纯文本sql查询中轻松做到这一点。

#4 楼

我同意存储proc的某些原因不是最佳做法。


业务和应用程序逻辑应该在代码中，而不是数据库中。将逻辑放入数据库中令人担忧。
您无法像其他常规应用程序逻辑中那样，用其余的应用程序逻辑对存储的过程进行无缝测试。
我找不到存储的过程。因为在编写代码时有利于测试首次编程。
在IDE中调试程序时，存储的procs不像应用程序代码那么容易调试。
SP的版本控制/源代码控制与常规代码

#5 楼

是的，存储过程为您提供代码重用和封装（软件开发的两大支柱），是的，但是要以能够满足其他敏捷设计目标为代价。一方面，它们更难以维护。如果我参与的项目有任何迹象，您最终可能会得到多个不兼容的SP，这些SP基本上完成了相同的工作，而没有任何好处。攻击，


否。他们不。正如我经常听到的那样，我什至无法开始猜测这个想法可能从何而来，这根本不是真的。它可以缓解某些类型的SQL注入攻击，但是如果您首先不使用参数化查询，那将无关紧要。我仍然可以'; DROP TABLE Accounts; -


并有助于提高速度（尽管DBA表示从SQL Server 2008开始，即使常规SQL查询运行了足够的时间，它们也会被编译）。


使用准备好的，参数化的语句（至少与我使用的几个DB一起使用）时，通常也会对它们进行编译。在您的应用程序开始执行查询时（或特别是当您多次执行相同的准备好的查询时），您认为SP所具有的任何性能优势都是完全没有意义的。

使用存储过程，恕我直言，是您必须进行一个复杂的，多阶段的查询，该查询从多个整理的数据源中提取。 SP不应包含低级决策逻辑，并且它们绝不应简单地封装否则为简单的查询。没有好处，只有很多缺点。

听您的DBA。他知道怎么回事。

#6 楼

我工作的所有三家公司都将存储过程用于SQL Server的应用程序逻辑。相反，我还没有真正看到过事情。但是对我来说，它们真是一团糟。通常没有很好的错误处理工具或带有存储过程的代码重用工具。

假设您有一个存储过程返回了要使用的数据集，如何在其中使用它将来的存储过程？ SQL Server上的机制不是很好。 EXEC INTO ...仅适用于一到两个嵌套级别（我现在忘记了）。或者，您必须预定义工作表并对其进行键控处理。或者，您需要预先创建一个临时表并让过程填充它。但是，如果两个人在两个他们从未计划同时使用的不同过程中将临时表称为同一件事，该怎么办？在任何普通的编程语言中，您都可以从函数返回数组或指向它们之间共享的对象/全局结构（函数语言除外，在函数语言中您将返回数据结构而不是仅更改全局结构... ）

代码重用如何？如果您开始将通用表达式放入UDF（甚至更差的子查询）中，则会使代码停顿下来。您不能调用存储过程来为列执行计算（除非您使用游标，将列值一个接一个地传递，然后以某种方式更新表/数据集）。因此，基本上要获得最佳性能，您需要在整个维护工作的噩梦中到处剪切/粘贴通用表达式...使用编程语言，您可以创建一个函数来生成通用SQL，然后在构建时从任何地方调用它SQL字符串。然后，如果您需要调整公式，则可以在一个地方进行更改...

错误处理如何？ SQL Server有许多错误会立即停止存储过程的执行，甚至会导致断开连接。自2005年以来，出现了try / catch，但是仍然存在许多无法捕获的错误。同样，错误处理代码上的代码重复也会发生同样的事情，您真的无法像大多数编程语言一样容易地传递异常或将异常冒泡到更高的层次.....

速度。数据集上的许多操作都不是面向SET的。如果您尝试进行面向行的操作，则要么使用游标，要么使用“游标”（当开发人员经常逐行查询每一行并将内容像游标一样存储到@变量中时）。 ..即使这通常比FORWARD_ONLY游标要慢）。在使用SQL Server 2000之前，我已经运行了1个小时，而我杀死了它。我在Perl中重写了该代码，并在20分钟内完成了代码。当比C慢20-80倍的脚本语言在性能上抽走SQL时，您肯定没有用SQL编写面向行的操作的业务。如果您使用CLR存储过程，请走开。但是出于安全考虑，许多DBA都不知道如何编写.NET程序或关闭CLR并坚持使用Transact SQL...。即使使用CLR，您仍然存在在多个过程之间高效地共享数据的问题。 。

通常，最难扩展的是数据库。如果您所有的业务逻辑都在数据库中，那么当数据库变得太慢时，您将遇到问题。如果您有业务层，则可以添加更多缓存和更多业务服务器以提高性能。传统上，另一台安装Windows / Linux并运行.NET / Java的服务器比购买另一台数据库服务器并为更多SQL Server授予许可要便宜得多。但是，SQL Server现在确实提供了更多的群集支持，最初它实际上没有任何支持。因此，如果您确实有很多钱，则可以添加群集，甚至可以做一些日志传送来制作多个只读副本。但是总的来说，这将比仅写缓存或其他内容花费更多。

还要看看Transact-SQL工具。字符串操作？我每天都会上Java String Class / Tokenizer / Scanner / Regex类。哈希表/链接列表/等等。我将使用Java Collection框架等。.NET也是相同的。C＃和Java都比Transact SQL更进化。 。

在plus上，存储过程对于处理大型数据集并应用多个查询/条件缩小其范围，然后再将其返回到业务层更为有效。如果您必须向客户端应用程序发送一堆庞大的数据集并在客户端上分解数据，那将比仅在服务器上完成所有工作效率低得多。对安全性有好处。您可以削减对基础表的所有访问，仅允许通过存储过程进行访问。使用XML之类的现代技术，您可以具有执行批处理更新的存储过程。然后，通过存储过程控制所有访问，因此只要它们是安全/正确的，数据就可以具有更高的完整性。

由于我们已经在编程语言方面进行了参数化查询，因此SQL注入参数不再真正适用。甚至在参数化查询之前，实际上大多数时候也可以使用一个replace（“'”，“''”）来工作（尽管仍然有一些技巧可以使用字符串的结尾来获得所需的内容）。 br />
总体而言，我认为SQL和Transact SQL是用于查询/更新数据的出色语言。但是对于编码任何类型的逻辑，请执行字符串操作（或heck文件操作...。您会惊讶于xp_cmdshell可以执行的操作...。）请不要。我希望找到一个将来不主要使用存储过程的地方。从代码可维护性的角度来看，这是一场噩梦。如果您要切换平台，也会发生什么（尽管实际上，如果您购买了Oracle / DB2 / Sybase / Sql Server / etc。您也可以通过使用所有可以帮助您的专有扩展来获得所有功能。 ..）。

令人惊讶的是，业务逻辑常常是不同的。在理想情况下，您会将所有逻辑放入存储过程中并在应用程序之间共享。但是根据应用程序，逻辑常常会有所不同，并且存储过程最终会变得过于复杂，人们害怕更改并且不了解其所有含义。使用良好的面向对象语言，您可以编写一个数据访问层，该层具有一些标准接口/钩子，每个应用程序都可以根据自己的需要进行覆盖。

#7 楼

这是几年前我为五巨头之一工作时的官方电话。理由是，由于SP绑定到特定的实现（PL / SQL，T / SQL和...），因此它们不必要地限制了技术选择。

经历了从T迁移一个大型系统的过程。 / SQL到PL / SQL，我可以理解该参数。我认为这有点让人难过-究竟有多少地方一时兴起从一个数据库真正转移到另一个数据库？

#8 楼

如何在服务器上对存储过程进行版本控制？

如果从版本控制将存储过程重新部署到服务器，则会炸毁存储执行计划。

存储过程不应可以直接在服务器上进行修改，否则您怎么知道现在正在实际运行什么？如果不是，则部署工具需要访问权限以将存储过程写入数据库。您必须在每个构建上进行部署（执行计划可能需要有所不同）。虽然存储过程不可移植，但SQL通常都不是（曾经见过的oracle日期处理-uggghhh）。

因此，如果您希望具有可移植性，请构建一个内部数据访问API。您可以像调用函数一样调用此函数，并且可以在内部使用所需的语言内置参数化查询，并且可以对它进行版本控制。

#9 楼

这与我学到的一切都太相反了。


您可能需要更多。 [笑]严重的是，存储的过程已下降至少10年了。自从n层取代客户端服务器以来，几乎已经有了很多。下降只是通过采用Java，C＃，Python等OO语言来加速的。进行讨论和辩论。这不是新事物，并且可能还会持续相当长的一段时间。 IMO，存储过程的反对者显然是赢家。


存储过程为您提供代码重用和封装（软件开发的两个支柱）

>非常正确。但是，体面的OO层也是如此。


安全性（您可以授予/撤消对单个存储过程的权限）


可以做到这一点，但由于严重的限制，很少有人这样做。数据库级别的安全性不够精细，无法做出上下文感知的决策。由于性能和管理方面的开销，也很难建立基于每个用户的连接-因此，您的应用程序代码中仍然需要一定级别的授权。您可以使用基于角色的登录名，但是您将需要为新角色创建它们，维护您以哪个角色运行，切换连接以执行“系统级”工作，例如登录等。最后，如果您的应用是是拥有的-您与数据库的连接也是如此。


保护您免受SQL注入攻击


除了进行参数化查询外，别无其他。您仍然需要执行此操作。


并有助于提高速度（尽管DBA表示从SQL Server 2008开始，即使常规SQL查询运行足够的时间，它们也会被编译） 。


我认为这始于MSSQL 7或2000。关于存储proc与内联SQL性能的争论，度量和错误信息很多-我全都放在YAGNI下。并且，如果您确实需要，请进行测试。


我们正在使用敏捷软件开发方法来开发复杂的应用程序。任何人都可以考虑为什么不想使用存储的proc的充分理由吗？


我想不出很多原因。 Java / C＃/任何第3种GL语言在封装，重用和可混合性等方面都比T-SQL强大得多。考虑到ORM不错，其中的大多数都是免费的。

建议“根据需要分配，但不分配更多”-我认为这些天的举证责任在SP倡导者身上。使存储过程繁重的一个常见原因是T-SQL比OO更容易，并且商店比T.SQL具有更好的T-SQL开发人员。或者，DBA停在数据库层，而存储的proc是dev和DBA之间的接口。或者，您正在运送半定制产品，并且存储的过程可以由用户定制。缺乏这样的考虑，我认为这些天任何敏捷软件项目的默认设置都是ORM。

#10 楼

考虑到上述所有情况，我想再添加一个。
SP的选择也可能取决于人们的选择。 SP，我相信这样的SP维护和调试非常复杂。甚至在很多情况下，开发人员本人都面临着在后台进行代码调试（例如说语言部分）时比在SP中容易得多的问题。

SP仅应用于简单的操作。那是我的选择。

#11 楼

我想同时介绍存储过程的一些利弊。我们在LedgerSMB中广泛使用它们，我们的规则是，通过一些非常具体的扩展，“如果是查询，则将其存储为过程。”

我们这样做的原因是为了促进交叉语言查询重用。老实说，没有比这更好的方法了。

最后，问题总是在细节上。如果使用得当，存储过程会使事情变得容易得多，而使用不当则会使事情变得更加困难。使用过的存储过程很脆弱。单独使用它们可以为您在您没有意外的地方（除了调用语法已更改之外）添加代码错误的可能性。单独使用会有点问题。层之间的内聚性太大，这会引起问题。在这个领域过分自信是一件坏事，因此需要在该领域的安全方面有丰富的经验。
由于上面的原因1，更改存储过程的接口有些问题，但这可能会变成如果涉及大量客户端应用程序，这将是一个巨大的噩梦。

上面的内容很难否认。他们发生了。支持SP和反SP的每个人都可能有关于这些的恐怖故事。这些问题并非无法解决，但是如果您不关注它们，就无法解决（在LedgerSMB中，我们使用服务定位器在运行时动态构建SP调用，从而完全避免了上述问题。只能对其他数据库执行类似的操作。）

肯定。假设您可以解决上述问题，您将获得：


设置操作中增强清晰度的可能性。如果您的查询很大或非常灵活，则尤其如此。这也导致增强的可测试性。
如果我已经在该领域工作过服务定位器，那么我发现存储过程可以加快开发速度，因为它们使应用程序开发人员摆脱了数据库问题，反之亦然。这在做对时会遇到一些困难，但并不难。
查询重用。 >

非事务逻辑。您发送了一封电子邮件，说明订单已发货，但交易已回滚...或者现在您正在等待继续使电子邮件服务器联机....或者更糟糕的是，由于无法到达而回滚了交易电子邮件服务器。...
松散地串在一起的许多小查询，散布着过程逻辑....

#12 楼

您为谁工作？

答案可能取决于您雇用的人，咨询公司或公司本身。对于公司而言，最好的情况通常对咨询公司或其他软件供应商来说不是最好的。例如精明的公司希望拥有比竞争对手持久的优势。相比之下，软件供应商希望能够以最低的成本为特定行业的所有企业提供相同的解决方案。如果他们成功了，客户将没有任何净竞争优势。

在这种特殊情况下，应用程序来来往往，但企业数据库却永远存在。 RDBMS要做的主要事情之一是防止垃圾数据进入数据库。这可能涉及存储过程。如果逻辑是好的逻辑，并且极不可能每年更改，那么无论使用哪种应用程序编写数据库，为什么都不应将其保留在数据库中并保持内部一致性？几年后，有人会问他们要问数据库的问题，如果阻止了垃圾邮件进入数据库，这将是可以回答的。

因此，这可能与您的DBA有关在一家咨询公司工作。他们编写代码的可移植性越强，它们在客户端之间重用代码的可能性就越大。他们可以在应用程序中使用的逻辑越多，公司与供应商的联系就越多。如果他们在此过程中留下了大麻烦，他们将获得报酬来清理它，或者再也看不到混乱了。不管怎么说，对他们来说都是胜利。



对于（很多）篱笆两侧的更多讨论，请阅读编码恐怖的讨论。 FWIW我倾向于那些主张SP的人。

#13 楼

切换数据库品牌和使用相同的存储过程非常困难。 />这无非是程序员与DBA的小便竞赛。

#14 楼

IMO这取决于。存储过程虽然占了上风，但不是最佳实践，也不是不惜一切代价避免的事情。精明的开发人员知道如何正确评估给定情况并确定存储过程是否是答案。就个人而言，我喜欢使用某种ORM（甚至是像原始Linq到Sql这样的基本ORM），而不是使用存储过程，除了可能用于预定义的报告或类似的报告外，但这确实是个案的基础。

#15 楼

使用不同的编程语言将业务逻辑划分到不同的层之间，始终是问题的根源。当您必须在不同的环境之间切换时，跟踪错误或实施更改会变得更加困难。 。这些不是很大的应用程序，但也不是简单的。例如20K-100K LOC。 （PL / SQL比T-SQL更适合于这种系统，因此，如果您只了解T-SQL，您可能现在就摇摇头……）

#16 楼

这是尚未提到的另一点：

代码生成工具和逆向工程工具不能真正很好地应对存储过程。该工具通常无法分辨proc的作用。 proc是否返回结果集？几个结果集？是否从几个表和临时表中获取结果集？ proc是封装的update语句，不返回任何内容吗？它会返回结果集，返回值和一些“控制台输出”吗？

因此，如果要使用工具自动创建数据传输对象DTO和DAO层（例如liferay的“服务提供商”），那么您就不容易这样做。

此外，当数据源是SP时，像Hibernate这样的ORM不能真正正常工作。数据访问最多是只读的。

#17 楼

单独编程，我无法抗拒编写存储过程。

我主要使用MySQL。我以前没有像PostGreSQL那样使用过面向对象的数据库，但是我在MySQL中对SP所做的事情就是抽象了表结构。 SP允许我设计这些原始动作，即使其下的数据库确实发生了变化，其输入和输出也不会改变。登录时，始终只需传递logIn和username。返回的结果是整数password。

当userId是存储过程时，现在我可以添加与初始登录同时发生的其他登录工作。与在编写逻辑服务器端时要做的（调用环境FETCH）->（获取结果）->（调用环境FETCH）系列相比，在存储过程中具有嵌入式逻辑的一系列SQL语句更容易编写。 >

#18 楼

我还要指出，存储过程确实在服务器上使用cpu时间。不是很多，但是有些。在工作过程中完成的某些工作可以在应用程序中完成。扩展应用层比扩展数据层更容易。

#19 楼

我同意Mark的观点，即社区确实已经离开存储过程已有相当一段时间了。尽管原始发布者提出的许多观点一次都有效，但我们已经使用了相当长的时间，而且正如另一位发布者所说，环境已经改变了。例如，我记得一个关于“在一天之内”使用SP的论点是获得的性能提升，因为它们的执行计划是“预编译”的，而每次执行时都必须“重新编译”来自我们代码的动态SQL。不再是这种情况了，因为主要数据库已经更改，改进，改编等。

这就是说，我们在我当前的项目中正在使用SP。原因仅仅是因为我们在仍支持旧版应用程序的现有数据库之上构建新应用程序。因此，在我们关闭旧版应用程序之前，很难进行架构更改。我们做出了一个明智的决定，即根据应用程序所需的行为和规则来设计新应用程序，并使用SP临时连接数据库，并允许SP适应现有的SQL。 。这可以说是以前的观点，即SP使得在数据库级别进行更改变得更容易，而无需更改应用程序代码。使用SP作为Adapter模式的实现对我当然是有意义的（尤其是考虑到当前的项目），并且可能是我今天真正看到它们可以使用的唯一论点。我们打算在更新架构时删除SP。但是，与公司发展中的所有其他事情一样，我们将看看这种情况是否会发生！ [咧嘴]

#20 楼

我只是想简要概述如何建议使用存储过程。我认为这根本不是一个坏习惯，就像其他人所说的那样，应该在适当的情况下使用它们。分离应用程序的业务逻辑，并导致数据库变得更加混乱和严格。换句话说，如果存在用于数据库操作的逻辑，该逻辑与任何应用程序的数据一致，则可以使用存储过程来保持数据的一致存储（有意义）。我认为，很好的例子是：一致的日志记录，一致的维护，使用敏感信息等。我认为数据库应该存储在包含业务逻辑的另一层中。简而言之，为实现一致性而进行的特定于数据库的数据操作可以使用存储过程，其中一致性超出了数据库完整性模式模型的范围。

#21 楼

除了不必要地分发业务逻辑，并将您与特定的数据库供应商联系在一起之外，我还坚信按照预期的目的使用技术。数据库就是关系数据存储。用它来存储数据，别无其他。

明智地选择工具，从长远来看，将为自己省去很多麻烦。