MIS数据库系统结构设计心得（以下情况充分使用了触发器的功能，而没有用到存储过程和视图，可以考虑一下哪里需要？）
1. 存在多种不同类型订单，相互独立
销售订单inscription，退款订单rembourse，甚至是不同类型货物的销售订单都分别建立一张表（除非它们之间十分类似）。
1）这样做的好处是方便统计，相互之间逻辑特别清楚而不会相互干扰。
2）为了快速的计算平衡数据，可以把inscription认为是一个主表，然后在里面分别建立字段，把其它订单的信息放在它的字段里面写清楚。
facture表的数据分别在这里使用especes,cheques,cb,virement字段来描述，不必使用ins_facture或者ins_recu字段
ins_tarif 订单原价，后面即使有还钱、坏账、优惠，全都与它无关
ins_recu 订单实收金额，全部使用触发器计算，方便核对，它不包括ins_rembourse,ins_reduction,ins_promotion产生的金额，但是facture里写入数据的时候本来想改写ins_recu金额，但触发器碰到订单编号为0怎么办？会出错吗？
ins_rembourse订单的退款（最初订单金额不变，另外生成退款表，同时用触发器往这里写。但实际退款要写到facture表）
ins_reduction 订单金额的损失（别人说明白订单中途作废，即使还要另外退款）
ins_promotion 订单优惠减价（当场对订单金额的改变，一般不予事后改变，那是reduction的情况）
ins_addition 订单金额加价，但一般不存在这种情况，而且可以同样可以使用ins_reduction字段
订单金额的最终平衡：ins_recu=ins_tarif-ins_reduction-ins_promotion-ins_rembourse
fc_perdu字段表示坏账（应收的货款，但别人不来交）。
情况一：有一个学生学费2000欧，只交了200欧，剩下1800欧坏账怎么平衡inscription的帐目？坏账表？
自我回答：坏账表肯定需要，否则仅仅知道坏账金额，不知道更详细的信息怎么行？至于怎么平衡inscription的帐目，很简单用触发器改写inscription表的坏账reduction栏目 1800欧（大概就是所谓的减记）。这样统计钱和坏账都不会出错，总体也能平衡。
情况二：有一个学生学费2000欧，只交了500欧，却要退款100欧，或者500欧，怎么样平衡帐目？
自我回答：退款表肯定需要，因为需要进一步记录退款的详细信息。
办法是在退款前，需要先找出原先的订单，然后选择退学退款，一方面写入rembourse表退款100欧（不用过脑子就可以填上），同时生成rembourse表的订单，另一方面计算订单的无效剩余金额1500欧（订单的坏账，既可以自动计算，也可以让使用人员手填），同时生成reduction表的订单，并用触发器写入inscription表中的reduction一栏，另外100欧写入inscription的rembourse一栏。
这样可以轻易知道(tarif2000-reduction1500-rembouse100)与(两次付款：实收500-退款100欧)是平衡的。或者碰到完全坏账tarif2000-reduction2000与实收0欧是平衡的。
2. 所有不同订单的钱被汇总到同一张facture表中。
而且每笔订单的现金、支票都是一条单独的记录。这样才符合标准会计准则。
3. 由于facture表分的过细，可能需要建立一张中间表（可能就是inscription），即详细描述每笔订单的总体情况。
可以直接在inscription表里增加especes,cheques,cb,virement字段，rembourse,perdu字段（实收的损失），reduction,promotion字段（应收的损失），分别描述相应的信息。最好用触发器生成，但也可以手工写SQL代码。此外，基本上不需要描述每一个时刻过来交了多少钱的那张中间表（新苹果里有），因为各种情况已经很清楚了。但也可以做一张表用来参考（使用触发器生成），如果好用并确定数据正确的话，也可以作为正式表使用和查询（一般不要予以直接插入数据）。
实收类型的表：
facture表只管收钱，需要对inscription表触发after insert,update,delete三种事件（delete和update极少出现，但也要有）。删除和作废都要触发。即删除是物理删除，作废是逻辑删除，但对记录实收的结果是一致的。
rembourse表只管退钱，需要对inscription表触发after insert,update,delete三种事件（delete和update可以没有）。
perdu表只管坏账，需要对inscription表触发after insert,update,delete三种事件（delete和update可以没有）。
应收类型的表：
reduction表（可能被退学表完全代替）只管订单修改或者作废
没有promotion表（因为一般指的是当时减价，时候吵架成功而产生减价，其实就是订单金额被改变，可以在reduction里记录数据）。
inscription订单可以单独作废，而不影响其它数据。但也有可能需要自动把facture删除或者作废。
既有应收，也有实收：
退学表reduction，或者attret，订单作废或者修改，但有可能牵扯到实收，因此这里的触发器要触发inscription表的reduction和rembourse两方面的信息。需要对inscription表触发after insert,update,delete三种事件（delete和update可以没有）。
细节：
我觉得为了方便统计，在facture里同时设置fc_especes,fc_cheque,fc_cb,fc_virement,fc_recu（收到多少钱）,fc_facon（支付方式），首次填入时，两个数据都同时手写。以后改变的时候，使用触发器，fc_especes改写fc_recu。
4. 删除订单的时候，是否把相应的facture、rembourse、perdu表的记录删除？
要根据实际情况而定，但一般来说是的。
删除人员信息的时候同理。
5. 最好不要使用流水号来连接不同表的数据，因为三层结构的时候，流水号不好处理。即使是CS模式也会出现多人使用的时候会抢流水号。
6. 只有数据量特别大，且存在复杂的多语言切换显示，才需要单独定义t_good_type和t_menu_type这种单独的类型列表，一般情况下使用字符串即可。
7. 不同类型的货物尽量合并。比如普通货物c_good和套餐c_menu（何况两者的字段内容极其相似），尽管使用两个表可以更详尽的分类，但是不利于统一搜索和输入货物消耗。我猜测c_good和inscription表一样，也是货物里的主表，无论这些货物如何细分也应该统一到这个表里。
总结：表是相同货物的一种归类，比如Client们都有十分相似的属性，货物们也有相似的属性。如果差异太大则可以设计成不同的两个表，但它们的相关子内容仍然可以共用一个表（比如inscription和rembourse以及facture之间的关系）。
8. 有的商品没有厂商，就不能进行cross join查询，正好使用left join。而且cxgrid自动让右边的数据无法编辑。
9. 两种库存统计方案：
（两种方法似乎不矛盾，第二种方案是第一种方案的补充）
1）一种办法是流水表buy/sell，然后用SQL做统计。
2）用一张Stock表示现有数量（永远是一张完美的现有库存表）：
如果有这个产品的库存，那么每次buy/Sell使用触发器修改它的数量。
如果没这个产品的库存，那么就添加上。