[讨论]主细表数据的录入逻辑问题

[Eray]

这几天在系统开发的时候,发现一些程序员的编程习惯很不好,这两天发现比较突出的问题就是主细表数据的录入逻辑问题.在这里,我将我的观点写出来用大家探讨,希望可以得到大家拍砖.补充一些建议.

主细数据库同时录入数据的时候，我认为有如下原则:


1 逻辑远比方便重要。
有的人喜欢将主表数据之前,生成细表数据。撇开数据库的主外键约束的情况不说,单单从逻辑上,也应该是先有主表数据,然后再有细表数据。
为了绑定显示方便，而将细表数据先存到数据库中，和逻辑上的混乱与造成的麻烦相比，远远得不偿失。



2 临时数据，临时存。
简单的临时数据，可以存到ViewState当中，复杂的（如发表一个新闻，带多个附件的）可以用Session.

Session可以放置任何对象。Ctype(Session("FJ"),ArrayList)可以存放很多东西，比如FileUpload。一些技巧应用能带来非常多的好处。但是，不要将临时数据存到数据库中。更不要指望用复杂的判断和清除数据、置标识等方式，貌似很有技巧，实际上是把简单的事情复杂了。



3 事务，事务！
主细表数据一个按钮同时添的时候，要有先有后，有事务，出错就回滚。我的习惯如下
Try
DB.StartTrans()
执行SQL1(主表)
执行SQL2(细表)
执行SQL3(细表)
执行SQL4(细表)
....
DB.Commit()
'提示成功
Catch ex As Exception
DB.RollBack()
'将ex信息提示出来
End Try

如果有一些是调用函数内部有Try了。或者某些执行返回影响行数为0，那就在本页面自己手动Throw一些错误，比如

If Myuser.Insert(参数，参数)=0 Then
Throw New Exception "增加人员失败"
End If
由于我的Insert函数中已经Try了，返回值根据是否为0判断是执行否有错误，那么我就手动Throw出相应的信息。



4 约束关系一定要完整



一个好的程序,不仅仅是代码要逻辑清楚,简捷,健壮.同时,对于数据库,其约束,索引,主键,外键一定要完整.一个好的约束,是避免错误数据产生和简化开发最直接有效的办法.

[wangping_li]

晕，怎么多发了一个， 不好意思

[mengxj85]

先做个标记，睡一觉起来再细看

[以专业开发人员为伍]

我喜欢拍这样的砖。如果有人认为公司中有这样拍砖的人会造成程序员之间的“不团结”，我想这是大大低估了程序员的品德了。但是，我确实看到有不少公司的中高层被那种玩办公室政治的人所左右，又要“团结”又要提高团队生产效率这是很困难的。

[mengxj85]

再顶一下，学习

[youaskme]

易用优先还是逻辑简单性优先这个问题困扰我好几年了，很多时候这两个问题是矛盾的，在设计时花费的脑汁很多, 欢迎大家继续讨论这个问题

[缪军]

本菜秧拙见：
1、主从关系的数据操作是否使用事务是由业务规则实现的
有可能必须用事务回滚
有可能不能用事务回滚
2、主从表关系要靠数据库设计表述和约束
好的数据库设计应该把多步操作压缩到最低限度，
楼主所描述的这种关系就属于多步操作；
多步操作尽量依赖MSSqlServer的事务控制（比如表间约束中的Delete层叠和Update层叠），
原因是设计可靠的事务要比设计数据库结构难得多；
我在早期写数据库应用的时候曾经使用大量的事务和触发器，
（触发器机制虽然是系统事务，但写了代码进去后就不一定了）
现在的数据库中根本就没有这两样东西；
3、8楼的观点我补充一下
如果从传统的程序设计角度看，8楼的观点没什么问题；
如果从工业角度看，一个project其实就是一条生产线上的产品，
你有几种项目开发模式（不是设计模式）就算有几条生产线，
不同类型的项目在不同的生产线上生产（比如进销存软件和硬件驱动程序），
这样我们大致划分出几种角色：
车间主任：部门经理(行政管理)
车间组长：项目经理（行政管理）也就是8楼所说的pm
工人：Coder（技术角色）
设计师：Designer（技术角色）；
UI、业务逻辑和数据访问都是封装好的，
Coder只知道有哪些组件、都是干什么的，他们只管调用；
就算是新产品，也是Designer交付新的UI组件图纸，由Coder根据图纸先生产UI组件
再由Designer反馈不断迭代后最终确定UI；
所以，一个成熟的软件工厂，部门经理和项目经理必须得了解软件生产的特点，
但不一定精通技术问题，有时候他们懂技术不一定是好事；
大部分的技术问题由Designer解决（当然他们拿的钱最多）；
小部分技术问题和体力活（比如代码组装、复制粘贴）由Coder解决（当然他们拿的钱少了）

我们再次回到楼主的话题，
程序员的编程习惯很不好，如果是技术问题，应该在设计阶段解决；
如果不是，那多半是管理问题了，那就找项目经理或部门经理了

[youaskme]

sp1234说的很有道理，很多东西是应该由项目经理或者设计人员来决定的，软件开发应该正规起来，虽然不需要像小日本那样让程序员做机械的让人发疯的填写函数代码的枯燥工作，但也应该有个起码的开发平台和设计方案，开发平台应该具有组织结构权限模块接口，以及在此基础上的数据录入系统，工作流系统，查询报表系统等中间件，以及控件库和类库。
设计方案应该根据公司的开发平台编写，那么很多平台中本身就有具有的东西就不需要在设计方案再体现了，比如平台有通用的查询功能，那么则不需要在设计方案体现“根据什么条件查询出哪些结果”，因为这些东西可以由实施人员(而不是程序员)在实施的客户现场进行灵活配置即可，比如开发平台中有工作流系统，那么就不需要在设计方案体现“第一步是哪些审批，第2步是哪些人审批...审批的转向条件是什么”，因为这些都是根据平台提供的功能来灵活配置的。
但是设计方案中有些东西应该体现：如数据库，界面，UML类图序列图等基本的东西
这样项目经理培训好开发平台的用法，然后交给设计方案，剩下的工作就只有给程序员进行测试程序了，呵呵，比较轻松
如果没有开发平台和详细的设计方案东西交给程序员，那项目经理就累吧，整天苦口婆心的教育，连一个界面录入验证都要讨论很长时间

[Ny-6000]

sp1234,说得确实有道理.
不得不佩服呀.

[以专业开发人员为伍]

遇到最“困难”的程序员，你直接写好测试用例然后让它随时可以读到，它写程序时会明明白白地做事。如果你总是事后教育程序员，虽然在你看来结果是一样，但是在我看其结果完全不同。这样做你对程序员所做的培训就是低级起点的。

“小日本”的做法也许灵活性不够，但是它却可以避免把问题仅仅用上纲上线的方式来解决。这就好像让你用砖砌一堵50米的围墙，连“民工”也懂得首先确定好墙柱的位置，然后再墙柱之间拉一根水平线，沿着水平线一层层地抬高水平线。如果你这些都不考虑，用不了多久就只能推倒重新砌墙。因此我们对程序员的日常培训很重要，但是pm做软件一定要跟砌墙的民工一样懂得自己应该先做什么。pm对程序员的培训值应该看作一种“拔高”而不是“推高”，好的pm不一定要求程序员的素质有多高就能顺利开发出畅销的软件。在实现代码之前先设计测试用例，这是pm应该有的技术，不要把这个推到程序员身上。

[qap22]

不懂，up

[xuebin_hu]

学习!

[以专业开发人员为伍]

因此，虽然我也觉得培训程序员是很重要很重要的工作，但是行事方法应该有所的不同。你的管理方式是先进的，你就够给程序员的更大的宽容的同时，他们之中比较聪明和真的想挣钱的人反而就会较早地符合你的拔高的需要。我看到你的第一条，我如果遇到这种情况会完全揽到到自己身上，因为那太明显是pm的责任了。而对后边的几条，基本上也是首先要警醒到你的开发过程没有相应的测试准备，因此质量是没有保障的。

我从你培训程序员的苦口婆心中，反而看出你缺乏“另外一手”项目开发技术。把任务分解然后压倒程序员身上，这只是手工作坊的做法。一个好的项目，程序员单纯为这个项目而编写的代码只有这个项目实际编写的代码的一半，另一半应该是你感觉管理、开发测试工具不合手而做的二次开发工作，或者为各种项目中间通用的核心技术而准备好的系统，普通的程序员不一定能够接触这一半的源代码，但是可以学会利用它来保证自己那一半代码开发时少走弯路。

[BlueskyWide]

好多功能在数据库和程序上都是可以完成的。

1.倾向数据库效率及约束方面的，建议使用数据库开发完成（如约束,索引,主键,外键）；
2.而倾向于界面会话的，可以使用界面程序(多使用类等)来完成。

关于session、事务和临时表可参考：
http://topic.csdn.net/u/20081119/16/edd5899f-c007-4574-9234-45acfbc532be.html

[Eray]

小顶一下,欢迎拍砖.

[以专业开发人员为伍]

我想最关键的是你选择的程序员应该是懂得界面程序设计的，而不是仅仅懂数据库编程的。如果程序员不懂，pm应该懂得，或者做出示例。最终，主细表应该在同一个aspx上录入，随时可以去修改主或者编辑细，没有什么先后之分。如果这个都做不到，除非你是随便写着玩的程序，否则尽早换程序员或者换pm吧。

[以专业开发人员为伍]

我不知道你的老板为什么有那么多闲钱去“培养”程序员，但是如果你不能在开发之前就明确表明界面验收要求，而是让程序员“替你做设计”并等着他们写出来之后再批评，虽然你可能是苦口婆心，但是我更倾向于你要付主要责任。这是我看到你的第一条就深深感触到的东西。程序员确实需要培养和教育，但是不是放到园子里随便吃食的野鸡，而应该是训练有素的群狼。例如我们去说明录入一个订单，总是要说明用户怎样录入订单，而对订单的实现方式才不去说明。而你连用户怎样录入订单都不去给人家说明，只给一个关系数据表结构吗？我重复很多次了，这种只给一个关系数据表结构就去指挥人家去开发界面程序的做法是非常有害的。

而对于第二点，我不知道你有没有租过和维护过asp.net应用程序所用的服务器，并且用于实际的生产。Session是随时（10分钟之后）会“丢失”的，有上百种任何人都完全说不完整的理由。

后面的几点，从某种角度看其实是无关痛痒的。pm不是去推着程序员去学习编程，而是拉动他们去学习。pm的工作做在前面，即预先设计好和声明你的产品检测方法，而不是“凭空下达任务”。而如果你没有在分配一个任务时预先说明你要不要去检测约束结果，或者要不要去检测SQL语句的顺序（我觉得你只要检测事务前后的状况而对中间过程根本不应该强求），那么程序员做出来的东西你都应该自己承担主要责任，这才是管理之道。

[cteddy]

讲的太好了
支持

[cteddy]

讲的太好了
支持

[NqIceCoffee]

呵呵，SP1234总能给人以惊喜

[NqIceCoffee]

个人感觉，如果在SP1234手下做事，肯定“痛并快乐着”