旅游公司有很多费用，比如支出费用一块，有
景点
团队编号，景点名称，平价人数，门票单价，优惠人数（比如儿童之类），单价
进店
团队编号，商店名称、人头数量、购物金额、提成比例
酒店
团队编号， 酒店名称 房价 房间数 房差（比如1个人住了1间房）价 房差数
有的费用很简单，可以归纳为
团队编号， 费用名称 费用说明 金额，这种我统一放在一起
等等（景点、酒店等的字段已经简化，实际上要稍微复杂些，但总体不算太复杂）
也就是总的支出费用由很多种，但每一种都有自身的字段属性，无法归纳在一张表里。
刚开始设计的时候，我是设计为进店表、用餐表、景点表.....每个表里存放各项明细，总金额通过实时计算后，也存入数据库，避免每次搜索时都要计算
但这样设计的问题在于，统计的时候非常麻烦，一个一个的表统计后，再求和。涉及到后期很多搜索之类，使用也不方便。扩展性也不强，增加一种新的支出类别，我就得增加代码，还是修改统计的存储过程
而且，还有个非常大的问题，有的费用是一个月一结，这种费用属于很多团队，我的设计暂时无法容纳这种费用，当然，设计时候，对方也没提到有这种特殊的费用。沟通后，对方也表示可以将这种费用分割到各个团队中（明细是有的），虽然通过沟通解决了，我也在想，万一真要设计进去，我这种表结构到底该如何设计呢。
最好是所有的支出费用，都统一在一张支出表费用中，但每种费用又有自身特性。还是请教各位大虾吧。
6 个解决方案
#1
该回复于2015-12-16 08:33:30被管理员删除
#2
你可以这么考虑，既然你的目的是为了便于统计，那么可以把一个团队的一次旅行看作一单，生成订单表，记录总金额，然后便是订单明细表，每一条记录就是对应订单表的具体收费项目及金额，再衍生出收费项目表，用于动态扩展收费项目，最后才是你上面那几张带有特殊字段的表，和订单明细关联作为订单明细的扩展使用
#3
关于抽象、扩展、一般化和具体化的设计问题，不仅仅是一个保存数据的问题，而是整个软件系统的工程问题。如果只把它看作（关系）数据库表设计问题，就太低级了。背景是你要有面向对象系统设计技术，你对于几十种将来的软件扩展行为都预见到其抽象、多态、代码重用的实质，才比较容易将数据表问题处理好（并且也能理解为什么要那样去设计）。
如果仅仅是（关系）数据库表设计问题，我前些日子回答了一个类似的问题。 http://bbs.csdn.net/topics/391866660
但是其实更大的背景，应该是关于流程控制、统计分析等等的“代码抽象复用”的问题。只有你能够将继承和多态的机制彻底使用，将你的应用程序的代码减到10分之一那么精简，才能体现出将数据结构设计面向对象技术相互适配的作用。
如果仅仅是（关系）数据库表设计问题，我前些日子回答了一个类似的问题。 http://bbs.csdn.net/topics/391866660
但是其实更大的背景，应该是关于流程控制、统计分析等等的“代码抽象复用”的问题。只有你能够将继承和多态的机制彻底使用，将你的应用程序的代码减到10分之一那么精简，才能体现出将数据结构设计面向对象技术相互适配的作用。
#4
非常感谢，我也是这么想的，关键的还是要把现实的问题转换成对象，然后抽象、多态、重用。但问题是我一直是个非专业的业余爱好者，也没在软件公司呆过，凭着爱好偶尔搞搞开发。
技术上的，就像学武，挑灯夜看，容易学会。软件工程是团队性质，像我这样不太接触团队以及大项目的，真的是只能脑袋里空想
#5
设计的确很重要，对维护和扩展都有影响。
你这数据项目也就20项左右，不算多
总金额不要存库里，免得数据失真
多种费用，可以读取这些费用到datatable，然后在内存里操作，或者在数据库里生成视图、临时表
客户增加功能，你可以考虑：从数据库的sys里找到某个表的所有字段（名字和类型），进行操作，而不是手工一个一个的写字段名，SQL语句不一定必须用存储过程，可以动态生成，这样你只需在数据库里增加字段就可以了，不用动代码
代码复用，我大致看了下，你这里共同的东西也就是：单价*数量=总价，可以把它写到基类里一个方法中，建议用ORM模型，一个对象对应一张数据库表，基类里定义的方法继承过来就行
数据库的表如何设计，关键不在于程序，在于业务逻辑的深入理解和实现设计，你列出所有项目（门票、景点名……），画图，理清实现思路，自然就有表结构了
你这数据项目也就20项左右，不算多
总金额不要存库里，免得数据失真
多种费用，可以读取这些费用到datatable，然后在内存里操作，或者在数据库里生成视图、临时表
客户增加功能，你可以考虑：从数据库的sys里找到某个表的所有字段（名字和类型），进行操作，而不是手工一个一个的写字段名，SQL语句不一定必须用存储过程，可以动态生成，这样你只需在数据库里增加字段就可以了，不用动代码
代码复用，我大致看了下，你这里共同的东西也就是：单价*数量=总价，可以把它写到基类里一个方法中，建议用ORM模型，一个对象对应一张数据库表，基类里定义的方法继承过来就行
数据库的表如何设计，关键不在于程序，在于业务逻辑的深入理解和实现设计，你列出所有项目（门票、景点名……），画图，理清实现思路，自然就有表结构了
#6
面向对象还是面向数据行，可以考虑建立个费用表a，包含团队编号，日期，费用金额等等基本字段，然后其他各种类型费用表b和此表建立1对1的关联，orm中体现为b等类继承了a类，一个月一结这个属性，应该也是放在表a内，团队编号未定而已
#1
该回复于2015-12-16 08:33:30被管理员删除
#2
你可以这么考虑，既然你的目的是为了便于统计，那么可以把一个团队的一次旅行看作一单，生成订单表，记录总金额，然后便是订单明细表，每一条记录就是对应订单表的具体收费项目及金额，再衍生出收费项目表，用于动态扩展收费项目，最后才是你上面那几张带有特殊字段的表，和订单明细关联作为订单明细的扩展使用
#3
关于抽象、扩展、一般化和具体化的设计问题，不仅仅是一个保存数据的问题，而是整个软件系统的工程问题。如果只把它看作（关系）数据库表设计问题，就太低级了。背景是你要有面向对象系统设计技术，你对于几十种将来的软件扩展行为都预见到其抽象、多态、代码重用的实质，才比较容易将数据表问题处理好（并且也能理解为什么要那样去设计）。
如果仅仅是（关系）数据库表设计问题，我前些日子回答了一个类似的问题。 http://bbs.csdn.net/topics/391866660
但是其实更大的背景，应该是关于流程控制、统计分析等等的“代码抽象复用”的问题。只有你能够将继承和多态的机制彻底使用，将你的应用程序的代码减到10分之一那么精简，才能体现出将数据结构设计面向对象技术相互适配的作用。
如果仅仅是（关系）数据库表设计问题，我前些日子回答了一个类似的问题。 http://bbs.csdn.net/topics/391866660
但是其实更大的背景，应该是关于流程控制、统计分析等等的“代码抽象复用”的问题。只有你能够将继承和多态的机制彻底使用，将你的应用程序的代码减到10分之一那么精简，才能体现出将数据结构设计面向对象技术相互适配的作用。
#4
非常感谢，我也是这么想的，关键的还是要把现实的问题转换成对象，然后抽象、多态、重用。但问题是我一直是个非专业的业余爱好者，也没在软件公司呆过，凭着爱好偶尔搞搞开发。
技术上的，就像学武，挑灯夜看，容易学会。软件工程是团队性质，像我这样不太接触团队以及大项目的，真的是只能脑袋里空想
#5
设计的确很重要，对维护和扩展都有影响。
你这数据项目也就20项左右，不算多
总金额不要存库里，免得数据失真
多种费用，可以读取这些费用到datatable，然后在内存里操作，或者在数据库里生成视图、临时表
客户增加功能，你可以考虑：从数据库的sys里找到某个表的所有字段（名字和类型），进行操作，而不是手工一个一个的写字段名，SQL语句不一定必须用存储过程，可以动态生成，这样你只需在数据库里增加字段就可以了，不用动代码
代码复用，我大致看了下，你这里共同的东西也就是：单价*数量=总价，可以把它写到基类里一个方法中，建议用ORM模型，一个对象对应一张数据库表，基类里定义的方法继承过来就行
数据库的表如何设计，关键不在于程序，在于业务逻辑的深入理解和实现设计，你列出所有项目（门票、景点名……），画图，理清实现思路，自然就有表结构了
你这数据项目也就20项左右，不算多
总金额不要存库里，免得数据失真
多种费用，可以读取这些费用到datatable，然后在内存里操作，或者在数据库里生成视图、临时表
客户增加功能，你可以考虑：从数据库的sys里找到某个表的所有字段（名字和类型），进行操作，而不是手工一个一个的写字段名，SQL语句不一定必须用存储过程，可以动态生成，这样你只需在数据库里增加字段就可以了，不用动代码
代码复用，我大致看了下，你这里共同的东西也就是：单价*数量=总价，可以把它写到基类里一个方法中，建议用ORM模型，一个对象对应一张数据库表，基类里定义的方法继承过来就行
数据库的表如何设计，关键不在于程序，在于业务逻辑的深入理解和实现设计，你列出所有项目（门票、景点名……），画图，理清实现思路，自然就有表结构了
#6
面向对象还是面向数据行，可以考虑建立个费用表a，包含团队编号，日期，费用金额等等基本字段，然后其他各种类型费用表b和此表建立1对1的关联，orm中体现为b等类继承了a类，一个月一结这个属性，应该也是放在表a内，团队编号未定而已