我们正在为客户设计薪资生成系统。
我们定位的组织具有以下层次结构： 公司 - ＆gt;群集 - ＆gt;业务部门（BU） - ＆gt;部门 - ＆gt;雇员
员工的薪水由各种薪水成分组成。 每个工资组件都有3个与之关联的规则，计算规则（计算组件为另一个组件的百分比，或固定数字的百分比或固定数字），资格规则（员工/部门是否有资格获得组件）和约束规则，限制组件的最大值和最小值。
这些规则是可编辑的，可由用户最终用户进行编辑。此外，这些规则是自上而下继承的，但如果在较低级别定义，则较低级别规则优先。
我们有一个数据库，其中包含出勤，离开，奖金表格，这些规则也应与这些表格互动。
客户端将为每个托管单独数据库实例的多个客户生成工资单。它们可能各自对每个组件有不同的解释，可能有不同的组件。
我们只希望支持SQL Server，而工资核算生成将是一项离线活动。
我们对使用这些规则的逻辑在哪里生成个别税务组成部分（包括税收减免，税务冲销，津贴等）存在分歧。
有些人提倡使用魔术SP，这会占用员工ID并生成该月的工资单。 其他人希望将逻辑分成单独的组件，这些组件将获取应用程序层中员工的相关数据并在那里计算这些组件。
我们的优先顺序是： 1.能够快速适应新客户的变化 2.长期可维护性 3.表现
1和2在这里超过3因为这将是一个离线活动。
可维护性和快速可定制性非常重要，我们将为不同的客户部署应用程序。 客户A可能有薪资成分规则为（（0.3 *基本）+800） 和客户B为（0.2 *基本）+（0.1 *出勤奖金）
SP会造成混乱，因为上面建议的规则将由最终用户指定，并且需要通过Web UI进行自定义。 我们将不得不从SQL解析公式。它有多难或多么容易？ 应用层（C＃.Net）在使用SP时有什么优势？
对现有系统架构的建议和指示非常有用。 ......是的，我们在系统的其他地方使用LINQ to SQL。
亲切的问候， Ashish Sharma
答案 0 :(得分：3)
我看到之后的唯一建议是从GoF设计模式书中查看策略模式。您可能希望使用脚本语言而不是主编译语言来完成策略，因为您可以更轻松地编辑它们。
答案 1 :(得分：0)
也许您想查看Agile Principles, Patterns, and Practices in C# 本书的核心示例是以敏捷方式设计薪资系统....
答案 2 :(得分：0)
有些人正在倡导神奇的SP 这将雇用员工Id和 生成该月的工资单。 其他人则希望将逻辑划分为 单独的组件将获得 员工的依赖数据 应用层并计算这些 那里的组件。
为什么不结合两者的优点？即，将逻辑分成写为SP的独立组件，从主SP？
调用这是所有数据处理，为什么要涉及“应用层”而不是调用主SP？
答案 3 :(得分：0)
取决于您在算法中有多少决策点。你预计会发生多大的变化。
如果您的处理是统一的，那么所有SP方法都可能为您提供最佳性能。这将允许您充分利用数据库缓存并避免网络瓶颈。请注意使用不等于等于/不等于的连接条件的游标和查询（如果有这些，通常可以通过通用语言更好地处理）。
如果您去申请，请考虑使用规则管理系统对数据库之外的规则进行编码。这将为您提供最大的透明度和灵活性。适用于Java的良好自由规则引擎是Drools（有些人也喜欢Jess，这是一个CLIPS克隆）。不确定什么是.Net产品，但在最坏的情况下，您可以将Drools包装在Web服务中并使用C＃。
答案 4 :(得分：0)
如果工资单生成是离线活动，那么我会在sps中执行此操作并从预定作业运行它们。应用程序根本没有理由参与其中。如果您希望他们能够按计划运行工资单，则应用程序可以调用相同的sp。
在执行工资核算时您真正需要考虑的安全问题： 不要在任何地方使用动态sql。没有用户应该拥有表的直接权限。所有权限都应该在sp级别（sps中没有动态sql，或者你必须在表级别设置权限）。这是为了限制用户实施工资单欺诈的能力，这是非常重要的。使用任何动态sql的任何工资单系统都有可能使公司员工通过直接访问表并执行应用程序不允许他们执行的操作来实施欺诈。这是为什么除了使用sps之外我不接受你的问题的任何答案的一个原因。
出于同样的原因，应在数据库级别强制执行业务规则。您不希望有人使用查询工具添加或更改不遵循业务规则的数据。这在工资单（或任何其他金融系统）中非常关键。尽可能使用约束，如果逻辑更复杂则触发。
您需要审核所有表格，包括记录谁对数据进行了更改以及何时进行。
要非常小心哪些用户可以更改工资核算。安全性再次成为真正的问题。仅仅因为我是一名主管并不意味着我应该能够改变任何员工的薪水。这很容易出错，所以在这里要非常小心。