我们正在为客户设计薪资生成系统。
我们定位的组织具有以下层次结构： 公司 - ＆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时有什么优势？
原帖在这里： Design Hints, Payroll System...repost ......但没有一个问题得到妥善回答。
对现有系统架构的建议和指示非常有用。 ......是的，我们在系统的其他地方使用LINQ to SQL。
亲切的问候， Ashish Sharma
答案 0 :(得分：3)
我总是试图回避将业务逻辑放在数据库层中。编写，调试和维护起来比较困难。此外，DB通常是最昂贵的规模层。如果您最终需要增强系统以支持更多用户，那么向系统添加新的Web服务器相对便宜且容易，但添加数据库实例会变得昂贵，因为每个数据库都需要许可证和额外支持。
答案 1 :(得分：0)
如果你将公式存储为例如JEP（对于java），那就不是问题了。只需将完整的公式保留为字符串：即：“pay =（（0.3 * Basic）+ 800）然后将其解析为树。
你可以看到一些关于信息的jep文档，并从中获取想法。对于您在此处发布的公式，实现简单求解器不应该有问题。
我的消化：
如果这些公式的复杂程度不高，你可以在你想要的任何一方做到这一点，因为它不会花费你那么多时间来处理它。
答案 2 :(得分：0)
如果您正在寻找将评估字符串中表示的公式的.Net解决方案，这里有一篇很好的文章，详细说明如何使用ANTLR and C#来创建计算引擎。有一个功能齐全的公式解释器，它解析字符串，构建AST，然后计算表达式。此外，计算引擎是使用访问者模式实现的，因此如果您希望执行诸如数据库查找之类的功能，则可以轻松地将自定义结合到您的解决方案中。
答案 3 :(得分：0)
你听说过反思或代表吗？