SQL Server 2008 中的业务逻辑
如果有 DBA 的话，我正在开发一个相当大的软件，目前最大的问题之一就是将业务逻辑放在哪里。虽然存储过程更容易即时修复，但处理要求可能会极大地减慢数据库的速度。我也不希望应用程序处理所有业务逻辑，因为我希望它成为一个“自我维持的实体”，不需要用户前端来操作。
我的想法是创建一个在某个中央服务器上运行的服务，并让客户端通过它进行连接。该服务将维护所有业务逻辑并充当所有数据库操作的前端。
有想法吗？是的？不？
我愿意接受我也缺少一些关键概念并且需要阅读一些文献。
If there are any DBAs out there, I'm making a fairly large piece of software and one of the biggest issues presently is where to put the business logic. While Stored Procedures would be easier to fix on the fly, the processing requirements would probably slow the DB down tremendously. I also don't want to have all of the business logic handled by the application because I want it to be a "self-sustaining entity" that doesn't require the user-front end to operate.
My idea, is to create a service to run on a central server somewhere, and have the clients connect through that. The service would maintain all the business logic and serve as a front-end for all the database operations.
Ideas? Yes? No?
I'm willing to accept that I'm also missing some key concepts and need to read some literature.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我建议您密切关注您所认为的业务逻辑与引用完整性约束之间的区别。
确保保持数据有意义相关的所有约束都在数据库层到位。即，如果您需要级联一些删除或插入，以及当您需要验证一些基本数据值以使一切有意义时......这些都应该在数据库中。
然后决定客户端、中间层服务器或数据库是否适合任何其他业务逻辑。
i would suggest that you keep a keen eye on the difference between what you think of as business logic, and what are the referential integrity constraints.
Make sure all constraints that keep the data meaningfully related are in place at the database layer. i.e. if you need to cascade some deletes, or inserts - and when you need to validate some basic data values in order to have everything make sense... these should all be in the database.
Then decide if the Client, or the middle layer server, or the database is appropriate for any additional business logic.
“业务逻辑”是什么意思？
我见过在客户端代码中完成聚合和其他基于集合的操作的情况，以及 SQL 中应该在其他地方完成的可怕的 RBAR 操作。
SQL 是一种有其用武之地的工具：如果您正在处理大型数据集、联接、聚合等，那么 SQL 就是您的最佳选择。其他任何事情都是对 SOA 理想的盲目服从。
我的方法是考虑存储过程或 SQL 正在做什么：它是中间层的一部分，以避免过程代码中基于集合的操作，还是它的纯数据完整性/持久性较低？
如果您的业务逻辑 100% 基于设置，那么可以说您不需要中间层（编辑：基于客户端代码），除非它非常薄。
What do you mean by "business logic"?
I've seen cases where aggregations and other set-based operations have been done in client code, as well as horrible RBAR operations in SQL that should be somewhere else.
SQL is one tool that has it's place: if you're working through large datasets, JOINs, aggregations etc then SQL is the place to do it. Anything else is slavish obedience to an SOA ideal.
My approach is to consider what the stored proc or SQL is doing: is it part of the middle tier to avoid set based operations in procedural code, or is it lower as pure data integrity/persistence?
If your business logic is 100% set based then you don't need a middle tier (edit: client code based) arguably, unless it's very thin.
多年来，我看到客户端应用程序来来去去，但数据库仍然存在。
所以现在我使用存储过程来处理大部分业务逻辑。三大优势：
Over the years, I've seen client applications come and go, but the database is still there.
So nowadays I use stored procedures for most of the business logic. Three big advantages:
将所有业务逻辑放在服务器端就可以了。
不在服务器端也可以。
事实上，这取决于你。
如果存储过程看起来不像 sql，您可以创建一个 CLR 存储程序。
这是类似的问题。
Having all business logic on the server side is fine.
Not having it on the server side is fine, too.
In fact, it's up to you.
If a stored procedure tends to look not sql-ish, you can make a CLR stored procedure.
Here's a similar question.
我强烈推荐传统的 n 层方法，其中至少有 UI 层、业务层（如 C# 程序集或 Java 等效层）和数据访问层。请参阅：http://en.wikipedia.org/wiki/Multitier_architecture。
我在一家公司工作，所有的业务逻辑都在进程中，维护成本比应有的要高得多，它限制了我们只能使用特定版本的sql server，它不可扩展等等。简而言之，除非您的应用程序是一种简单的一次性的东西，我不会将任何业务逻辑放入数据库中。
I'd highly recommend a traditional n-layer approach, where you have at least UI layer, business layer (like a C# assembly or Java equivolent), and data access. See: http://en.wikipedia.org/wiki/Multitier_architecture.
I worked for a company where all the business logic was in the procs, and maintence costs are much higher than they had to be, it limited us to a specific version of sql server, it wasn't scalable, etc. In short, unless your application is a simple throw away kind of thing, I'd not put any business logic in the database.