请问做过人事系统的朋友，在设计工资表时一般是怎样设计的。
我知道的有两种方式：
1、把工资款项以多条记录的形式存储，如张三有基础工资、职务工资、工龄工资。。。一共10个款项，则数据库中存储10条记录。
2、把工资款项以列的形式存储，如table A ,col1、col2、col3。。。

第一种对性能肯定有影响，而且汇总查询起来很繁琐；第二种列数不好确定，不知道总共需要建多少列，而且很多列都是没用的。

其实还有第三种方案，就是table A ,col1、col2、col3。。。，对不同的员工类型不同的列代表不同的含义。但是也有缺陷，其一就是列数不好确定，另外就是查询起来也很麻烦，要在程序中不同的转换。

大家一起探讨探讨。

飘过，觉得第一种好，汇总可以利用视图 (group by创建) ，查询起来应该会简单一些

第一种效率会比较低的

肯定是第一种好。如果是第二种，如果工资类型增加，则需要修改代码。

第一种方式，是纯逻辑设计，或许在逻辑上比较简洁， 但由于和实际的工资单结构大相径庭，无法在上游工程中分析和解决设计上的问题，项目中会存在很大风险，质量控制也非常困难。至于将来的扩张性，牺牲设计方案的可分析性来保障是很不值得的。
第二种方式是接近实际的设计，因为可以同实物对照它分析起来会很容易，比如说在设计阶段就能够通过和工资单的对比来发现是否有缺失的字段等等。使用这样方案，程序设计和质量监控都很容易推荐使用。
第三种方式则完全脱离了关系型数据库的模式，它会做成什么样偶完全无法想象，不建议在产品开发中使用

QUOTE:

---

原帖由 lodge 于 2008-2-22 18:54 发表
第一种方式，是纯逻辑设计，或许在逻辑上比较简洁， 但由于和实际的工资单结构大相径庭，无法在上游工程中分析和解决设计上的问题，项目中会存在很大风险，质量控制也非常困难。至于将来的扩张性，牺牲设计方案的可分析性来保障是很不值得的。
第二种方式是接近实际的设计，因为可以同实物对照它分析起来会很容易，比如说在设计阶段就能够通过和工资单的对比来发现是否有缺失的字段等等。使用这样方案，程序设计和质量监控都很容易推荐使用。
第三种方式则完全脱离了关系型数据库的模式，它会做成什么样偶完全无法想象，不建议在产品开发中使用

---

我认为可以使用第一种，然后查询时使用动态的生成列。
单独建立表存储不同的类型，可以设置不同的类型的浏览权限。

QUOTE:

---

原帖由 trigger_lau 于 2008-2-28 00:41 发表



我认为可以使用第一种，然后查询时使用动态的生成列。
单独建立表存储不同的类型，可以设置不同的类型的浏览权限。

---

恩, 先明确一哈两种方式
第一种
姓名*, 款项*, 工资额

第二种
姓名*, 基础工资, 职务工资, 工龄工资,。。。

第一种方式和我们见过的工资单很不相同, 很多要求都木有明确, 因此 在前期设计阶段无法确定设计方案是否和需求相符. 只有等到项目实施阶段, 把工资的各个款项都写进DB, 才能够根据运行结果作出判断, 这种方式提高了抽象的层次, 赋予了系统很大的可扩张性, 但同时却牺牲了设计方案的可分析性. 这个牺牲的直接后果, 就是把本来可以提前测试的功能点, 推迟到系统测试之后, 既加大了系统测试的压力, 也大大增加了项目在最后阶段出现重大BUG的可能性, 提高了开发实施的风险. 如果是为少数企业做定制开发, 这种设计弊大于利. 但是, 如果是做用于二次开发的管理模块, 比如说做SAP的ERP模块, 这个方案还是有可取之处的.

另外, 可为第二种方案预设一定数量的保留字段, 以便将来增减款项时使用. 比如说, 使用以下方式


工资表
姓名*, 基础工资, 职务工资, 工龄工资,。。。,预备款项1,预备款项2,预备款项3。。。

如果所有员工的工资构成都相同则可以这么做
工资构成表(仅一条记录, 使用注册表或者INI文件也可以)
基础工资标志, 职务工资标志, 工龄工资标志,。。。,预备款项1标志,预备款项2标志,预备款项3标志。。。

如果每个员工的工资构成都不同, 则这么做
工资构成表(也可以考虑和工资表合并)
姓名*, 基础工资标志, 职务工资标志, 工龄工资标志,。。。,预备款项1标志,预备款项2标志,预备款项3标志。。。

[ 本帖最后由 lodge 于 2008-2-28 06:36 编辑 ]

个人感觉还是第一种方法方便些，第二种方法实用

设计表要保证所以字段信息与主键的关联唯一

在Oracle下, 我会把它设置成Nest Table形式
另外像 基础工资、职务工资、工龄工资 这种最基本工资外, 其它都应该是根据职位或工龄的比例来的
因此可以设置一个比例表, 再Join计算(在其它DB,如MSSQL中我常采用这种做法)