请教数据表的规划

ycxchen

工人的姓名、身份证号码等基本信息一般是不变的，但工序会变的，所以，我还是建议建立一对多关系，日后设立查询、窗体等方便，10楼版主已详细写了个例子，楼主要细心研究。

简

谢谢楼上各位热心的朋友，让我懂得了不少东西。

简

我想再请教一下，以todaynew老汉的表结构数据库为例，我想统计加工表中工序id为刨的个数，其程序代码该怎么写呢？

我原来写成me.txt0=DCount("*", "加工表", "[工序id]<> '刨'")，运行错误，我也知道原因是工序id值是长整型，而刨是字符型，类型不匹配。

那么，像这种情况，代码该怎么写呢？难道应该是：
me.txt0=DCount("*", "加工表", "[工序id]=1”)

根据工序id的字段值，我不一定能晓得刨对应1，车对应2，磨对应3呀……

还有，既然工序id值是长整型，为什么字段值能保存成字符型如刨，钳等呢。

在加工表中，我需要通过工序（或工人）进行大量的筛选查找，建立查询，报表等，这时在加工表中，我应该将工序（或工人）设计成工序id（工人id）好呢，还是工序名称（或工人姓名）好呢？

todaynew

简 发表于 2011-5-27 21:30
我想再请教一下，以todaynew老汉的表结构数据库为例，我想统计加工表中工序id为刨的个数，其程序代码该怎么 ...

呵呵，鬼打架的，你也不能一口气搞这么多问题呀。

1、统计问题应该如下解法：
Dcount("*","加工表","工序id=" & Dlookup("工序id","工序表","工序='刨'"))

2、组合框或列表框的绑定值和其显示的字段可以不一样，通常我们都是将记录的ID作为绑定值，但又不想显示出id（因为id枯燥无味可理解性很差）。于是乎我们就将id的列宽度设置为0，而将要显示的字段列宽度设置为一定的长度。这个设置在表、查询的查阅中设置，如果是窗体的组合框或列表框控件，则在数据属性和格式属性中设置。
这个问题要这样去理解，你的组合框或列表款给你显示的值并不一定是保存的值，而绑定的值（也许你看不见它）才是你保存的值。

3、一个表的ID是标识一条记录唯一性的字段，也是若干张数据表之间建立关系的字段。所以通常外键要使用主表中的ID，这个观点与后期的数据查询和其他方面的使用方便与否没什么大的关系，或者说这一方法已经为数据的后期使用奠定了基础。比如说你希望查询出某个工序的数据，而加工表中又只有ID没有工艺名称，那么你可以以加工表为基础将工艺表和工人表拖入到查询设计视图中，将工艺名称和工人姓名字段拖入到查询中以此建立一个名曰“加工查询”的查询，并以这个查询作为子窗体的数据源就可以了。

简

todaynew 发表于 2011-5-28 19:52
呵呵，鬼打架的，你也不能一口气搞这么多问题呀。

1、统计问题应该如下解法：

回todaynew老汉：

看了你的回复，我大概晓得应该如何处理了，但我心中还有个疙瘩没有解开。以你的表结构为例，我以往在没有考虑表结构时，在加工表里我就会如下图设置：


然后在子窗体里，对工序我设置如下：

我觉得这样的设置一目了解，不需要拐弯抹角，当然，关系也就不起作用了。

看了一些实例后，发现对于类似情况，它们在表结构上都没有像我这样设置和设计，而是通过关系，通过一对多，一对一之类的来处理。我就觉得挺奇怪，因为我没有发现我以前那样的设计有什么不妥，而且那样的设计也没有出现什么数据的重复性，相反我还认为我以前那样设计在程序代码上处理更方便，就比如统计在加工表里统计工序为刨的个数，如果用我以前的设计方法，即用工序字段，其代码就是：DCount("*", "加工表", "[工序]<> '刨'")，如果用工序id字段，代码Dcount("*","加工表","工序id=" & Dlookup("工序id","工序表","工序='刨'"))，这还反而麻烦呢。

简

还有：

我看前面有两个朋友认为，只需要tblgx表(工序表)和tblgxgr表(工序下的工人)两个表即可，为什么他们会有这样考虑呢。如果工人较多，近百个，是不是还是单独建立工人表要好些呢。

另外todaynew老汉说，工人与工序的联系是在有关描述加工的数据表中存在的。这种存在可以根据情况出现两种表达方式……所以老汉建立工序表，工人表，以及让工序和工人发生联系的加工表。

我建立tblgxgr表的目的，一是生产的实际情况，有工人从事两个工序，比如说张三工人在刨和铣两个工序里操作。二是为了提高输入效率，三是在筛选工人时缩小选择范围，四是为了统计的需要。比如说，我要输入工人彭五的名字，打字慢的同事不想输入的话，可能就在组合框里挨个挨个找，如果知道彭五所属的工序是磨的话，就可以先在工序组合框里选择磨，然后在工人组合框里就自动筛选出磨工序下有哪些工人，这样就可以快速选择出彭五工人来。为了统计的需要，打个比方说，我需要了解这个月刨工序接受了多少加工任务，产量是多少等，即按工序来进行统计。

这样分析来，tblgxgr表还有没有必要单独建立呢。

todaynew

简 发表于 2011-5-28 23:49
还有：

我看前面有两个朋友认为，只需要tblgx表(工序表)和tblgxgr表(工序下的工人)两个表即可，为什么他 ...

你还没有理解数据库设计的基本原理，呵呵。对于你的这几个问题，需要用倒叙来加以说明了。先从最后的问题来说吧。

　　1、所谓工人表其实不应该是工人表，而应该是员工表。一个管理系统通常需要涉及到人，为什么呢？因为人是生产力的第一要素，没有人什么事情都办不成。就一个企业来看，人员所从事的工作是多方面的，有从事管理的管理干部、销售人员、财务人员、劳资人员等等，有从事技术工作的设计人员、检验人员等，还有从事一线生产人员的工人等等。人员有其共性，比如他们都有姓名、性别、年龄、岗位、隶属的部门等等，员工表所起的作用就是独立的保存这些有共性的信息。
　　也就是说，我们通常应该把具有相同属性的一类对象用一张数据表来保存数据，企业管理的要素无法是人财物，以及人财物相互作用的各种过程各种结果。这些东西经过合理的分类，都可以形成相对独立而又有联系的对象，数据库的设计就是将这些对象数据化的分配到各个数据表中，并通过关系这样一些手段，来描述他们之间的联系。
　　数据表大体上可以分为两类，一类是诸如员工表、部门表、产品表、材料表、工艺表、检验项目表等等，他们的特点是与时间的联系不紧密，也就是相对于时间的变化很小，这些数据表我们称之为基础资料。还有一类数据表是与时间紧密联系的（可能时间是隐形的），比如订单表、销售表、入库表、加工表等等，这些数据表我们可称之为动态数据。
　　一般来讲，动态数据的数据表中都会存在基础资料数据表的ID，比如课程表中存在班级ID、学科ID和教师ID，加工表中存在工序ID、员工ID、材料ID。保存基础资料表中的ID，而不是保存基础资料表中的部分字段或全部字段，就是为了减少数据冗余。由于数据表的ID唯一性的定义了一条记录，所以保存数据表的ID也就是保存了该条记录。
　　数据表的ID是强调数据表中记录的唯一性，但并不是说数据表的其他字段不能替代这个功能，比如说工艺表的工艺名称，员工表的姓名（只要企业内没有重名的职工），所以在某些情形下，数据表是可以不必单建ID字段的。但是通常我们都愿意单独建立ID字段，这又是为什么呢？这是因为对每个数据表单独建立ID可以统一ID的数据类型和编码规则，这样就对后期的编程按照统一的规则进行数据处理提供了方便。
　　简言之，一个管理系统中一定需要建立一个人员表（可以叫做学生表、教师表、员工表、用户表等等），也一定需要设一个人员ID字段。

　　2、简化操作特别是简化录入操作的问题，与数据表结构设计有关系但不是影响数据表设计的根本原因，也就是说在数据表设计阶段可以暂不考虑录入问题的简化，只需考虑一般的设计规范。筛选人员的方法有多种手段，比如可以用姓氏筛选，还可以用拼音助记码筛选，还可以用部门组合框加人员组合框联级筛选等等，工序的筛选和统计也是一样。这些操作都与数据表设计没什么太大关系，只是后期的处理技巧而已。

　　3、DCount("*", "加工表", "[工序]= '刨'")的简单与Dcount("*","加工表","工序id=" & Dlookup("工序id","工序表","工序='刨'"))的麻烦，实际上是一个战略和战术的问题。红军长征时四渡赤水，连续走了几个大的迂回，当时部分指战员包括林彪、彭德怀等军团司令员都不理解，认为不应该走弓背而应该走弓弦。但最后的实践证明，毛泽东在运动中调动敌人消灭敌人摆脱敌人的战略是正确的。也就是局部的麻烦，不代表全局的麻烦，牺牲局部才可能带来全局的胜利。这就是我前面反复强调的全局性的观念、全局性的视角、全局性的思维。加工表中我们不用一个文本型的汉字字段作为ID，而以一个自动编号的数字型的字段作为ID，在统计时可能有些麻烦，但在做筛选、运算、排序等等方面都极大的简化了。花费了一个语句的麻烦，带来了几个语句，数十种处理的简化，你说是麻烦还是简单呢？
　　在数据库设计时，要有进得去出得来的本领。所谓进得去，是指能关注到细微末梢的各种情况各类情形；所谓出得来，是指能忽略细节，站在全局的高度看问题。只有这样才能不畏浮云遮望眼，只缘身在最高层，否则就是一叶障目不见泰山了。

　　4、最后再强调两点。第一点是数据库的设计一定要以表结构设计为基础，这个问题通常被初学者所忽视，我经常看见版友上传的问题实例中，表结构不合理的占绝大多数。不合理的表结构会带来一系列的麻烦，而合理的表结构可使程序极大的简化。第二点是初学者一定要使用关系视图来建立表间关系，Access中的这个工具非常好，它图示化的直观描述了数据关系，对于判断表结构是否合理有重要作用。我个人的体会是，如果关系视图中的连线交错的特别复杂，一定是表结构设计出现了问题，在这种情况下我会对表结构进行调整，使表间关系简洁明了。

ycxchen

老汉真是顶级老师，说理很详细，难得！

简

todaynew 发表于 2011-5-29 10:12
你还没有理解数据库设计的基本原理，呵呵。对于你的这几个问题，需要用倒叙来加以说明了。先从最后的问 ...

谢谢老汉，让你费心了，能不能将就我的例子进行修改，让我再好好学习与消化呢。

todaynew

简 发表于 2011-5-29 16:11
谢谢老汉，让你费心了，能不能将就我的例子进行修改，让我再好好学习与消化呢。

14楼的例子应该能说明问题了。