如果有任何DBA，我正在制作一个相当大的软件，目前最大的问题之一是放置业务逻辑。虽然存储过程更容易动态修复，但处理要求可能会大大降低数据库的速度。我也不希望应用程序处理所有业务逻辑，因为我希望它是一个“自我维持的实体”，不需要用户前端操作。
我的想法是创建一个服务，在某个地方的中央服务器上运行，让客户端通过它连接。该服务将维护所有业务逻辑，并作为所有数据库操作的前端。
想法？是？否？
我愿意接受我也缺少一些关键概念，需要阅读一些文献。
答案 0 :(得分：4)
我建议您密切关注您认为的业务逻辑与参照完整性约束之间的区别。
确保所有保持数据有意义相关的约束都存在于数据库层。即如果你需要级联一些删除或插入 - 当你需要验证一些基本数据值以使一切都有意义时......这些都应该在数据库中。
然后确定客户端，中间层服务器或数据库是否适合任何其他业务逻辑。
答案 1 :(得分：3)
“业务逻辑”是什么意思？
我见过在客户端代码中完成聚合和其他基于集合的操作的情况，以及SQL中可能存在于其他地方的可怕的RBAR操作。
SQL是一个有它的工具：如果你正在处理大型数据集，JOIN，聚合等，那么SQL就是这样做的地方。其他任何东西都是对SOA理想的盲目服从。
我的方法是考虑存储过程或SQL正在做什么：它是中间层的一部分，以避免在过程代码中基于集合的操作，还是作为纯数据完整性/持久性降低？
如果您的业务逻辑 100％设置为基础，那么您可能不需要中间层（编辑：基于客户端代码），除非它非常薄。
答案 2 :(得分：2)
多年来，我看到客户端应用程序来去匆匆，但数据库仍然存在。
所以现在我使用存储过程来处理大多数业务逻辑。三大优势：
答案 3 :(得分：1)
在服务器端拥有所有业务逻辑很好 在服务器端没有它也没关系。
事实上，这取决于你 如果存储过程看起来不是sql-ish，则可以创建CLR stored procedure。
答案 4 :(得分：0)
我强烈推荐传统的n层方法，其中至少有UI层，业务层（如C＃程序集或Java等价）和数据访问。请参阅：http://en.wikipedia.org/wiki/Multitier_architecture。
我在一家公司工作，所有的业务逻辑都在procs中，而且维护成本远高于它们，它限制我们使用特定版本的sql server，它不具有可扩展性等。简而言之，除非你的应用程序是一个简单的丢弃的东西，否则我不会在数据库中放置任何业务逻辑。