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