【Access小品】版友简的故事---三论数据表设计

todaynew

　　版友简，川妹子是也。于一企业从事模具工艺设计工作久矣，便欲起意用Access辅助设计工作。初，只做些工艺数据的导入导出，不幸被领导窥见，令其写一更广泛之管理程序。所谓无知者无畏，加之简胆大，不知深浅，便欣然领命。上得手来，却是乱麻一堆，且不说各行隔山管理的诸多领域丈二和尚摸不着头脑，就是这个看似简单的Access也还久久进不得门来。

　　这两日，简妹子发贴问数据表设计问题，在下看来是个极大的转变。以往简妹子是不屑于数据表问题的，胡乱弄些表折腾出窗体就万事大吉了。于是弯路走了十万八千里，算是撞了南墙，吃了苦头，便也算是翻然醒悟了。不过弯路走多了，还是有些习惯性的搞法。总还是那种站在十八层楼上，想着怎么修改地基的问题。于是你要和她说数据表结构设计怎么搞法，她一定要准备一堆筛选的问题、计算的问题，来说明数据表结构应该是这样应该是那样。

　　和简妹子说事不能急，只能耐着性子反复说明数据表结构设计阶段不必过多的考虑后期的问题，要能用实例不断的证明她说的所有后期的问题都能得到解决。假如有一点鸡毛蒜皮的小问题，她就会说这样不对，还是应该按她说的方法进行表结构的设计，哪怕这种设计极为不合理，她都会坚持自己是对的。

　　版友简对于数据表的疑惑具有典型意义，几乎非计算机专业的初学者都不懂的也不重视数据表的设计，功夫都下在了窗体、查询、代码等上面了。在我看来这都无异于沙地建楼，有百害而无一益。这个实例是写给简的，想要证明的是表结构设计阶段重点考虑的是数据之间的关系，而非后期处理的问题。所有基于数据表的后期处理的各种问题，都可以找到合理便捷的处理方法，并不需要在数据表的设计阶段过多考虑。

　　如果版友对本实例看得迷惑不解的话，可以看看在简的《请教数据表的规划》中的详细讨论，相信会对你理解本实例有所帮助。

roych

由于目前市面上大多数书籍都是从实例上介绍的，对于表的设计介绍得相当少，甚至“基础表”这个说法都极少提及。我觉得有必要写一个关于基础表设计的教程，不知道老汉认为如何呢？

todaynew

roych 发表于 2011-5-30 20:25
由于目前市面上大多数书籍都是从实例上介绍的，对于表的设计介绍得相当少，甚至“基础表”这个说法都极少提 ...

呵呵，然也！

鱼儿游游

LZ文采一流，佩服之至。

gxy1000

几乎非计算机专业的初学者都不懂的也不重视数据表的设计，功夫都下在了窗体、查询、代码等上面了。



是的呀！！！真的是这样的！！深有体会

xuwenning

roych 发表于 2011-5-30 20:25
由于目前市面上大多数书籍都是从实例上介绍的，对于表的设计介绍得相当少，甚至“基础表”这个说法都极少提 ...

如果我每记错的话——表结构设计在数据库原理上就已经介绍过了
而且英文版的书籍介绍表结构的书也多
以前看过一本英文的关于表结构的书具体名字不太记得了，当时E文很烂（^_^,现在也烂）没太看懂

简

呵呵，让各位朋友见笑了哈。

回复老汉，建立数据表的目的，不就是为了查询，计算，报表之类的操作吗？我看你的实例，对联合查询有些疑问，我觉得，联合查询联合的是加工表和工人表，根据加工表中工序和工人的对应关系来建立的筛选，但这个筛选关系我觉得似乎不能适应未来的变化，比如张三调离了刨工序，李四辞职没在这个工厂工作了，这个时候加工表中刨工序里就没有张三，而车工序里也没有李四。但在以前的记录中，依然需要保持张三在刨工序，李四在车工序的记录。

还有“待确定”的问题，我想问，为了应付实际中的问题，除了工人ID需要待确定外，是不是像工序ID，产品ID，还有类似一对多，一对一关系中关键字段的ID都需要待确定为好呢？

pq318

todaynew 版主的文采领教过很多次了，你说的真的很有经验，技术也很好，数据表处理真的很头疼，我学的是刘小军的，不知技术怎么样，能有好的推荐吗

sgrshh29

回复 todaynew 的帖子

同一楼主看法。

todaynew

简 发表于 2011-5-31 09:50
呵呵，让各位朋友见笑了哈。

回复老汉，建立数据表的目的，不就是为了查询，计算，报表之类的操作吗？我 ...

１、关于联机筛选的问题解答：

　　联机筛选的目的只是为了缩小范围，而不是确定记录。给定一个范围后，是需要人脑进行判断和选择的。这是一个基本前提。
　　
　　一个小型的企业，人员较少，辨识容易。张三是否离职，李四是否调离现岗位，对于录入数据的人员来说，不是障碍。这是另一个前提。

　　在这两个前提下，你可以回答这问题：目前的处理方案会导致录入人员极高的差错率吗？这种差错无法纠正吗？

　　管理学认为任何一件事情都没有绝对完美的处理方法，只存在相对合理的处理方法。这是我们寻找解决问题方案的基本出发点。

２、关于“实施参照完整性”问题的解答

　　对建立了实施参照完整性完整性的若干数据表在数据录入时，外键无法同时录入的问题，其解决方案至少有三种。其一是在主表中建立一条系统专用的记录，比如可以叫做【待确定】，这样可以保证在子表外键录入时均可做出选择；其二是取消表间的“实施参照完整性”，由于没有这个关系属性，因此子表的外键可以为ｎｕｌｌ或者其他的值；其三是用一个临时表（该表与子表字段相同，未与其他表建立关系），进行数据录入，当数据完整后再追加到子表中。我一般采用第一和第二种，因为我不想打破实施参照完整性。

　　这三种方式可以交替使用，具体在什么情况下用何种方法，用到什么程度，要依据数据录入作业的情况来确定。比如采用第一种方法时，如果工序必须在首次录入时就选定，那么工序表中就无必要存在【待确定】记录。

　　这类问题的处理在数据库设计中不应该过多，如果过多只可能是两个问题，其一是程序设计人员对情况不了解，思路不清晰，此情况下要学习科学发展观，用马列主义毛泽东思想邓小平理论武装头脑；其二是管理工作本身存在缺陷，使得各岗位的人员面对工作经常处于一种不确定，不明白，不知所措的状态，此种情况下就需要管理流程再造了。