请教数据表的规划

简

我知道，为了避免数据的重复，实施参照完整性，在数据表里需要采用一对多，一对一等关系，我想了解两个问题：

1.有没有必要建立关系？有个朋友给我说，没必要建立关系之类的，因为在窗体输入数据时就可以判断和确定数据之间的关系。

2.像我这附件里的几个表，应该如何规划才合理呢。

这几个表是：tblgr(工人)，tblgx(工序)，

tblgxgr(工序下的工人，字段值是工序和工人的名称)

tblgxgr_id(工序下的工人，字段值是工序和工人的id)

那么，从数据库的后期设计比如窗体，查询，报表等及维护来看，工序下的工人表应该采用tblgxgr表好还是tblgxgr_id表好呢，为什么呢。

附件：  

roych

1、尽管建立了关系可以级联删除，便于删除相关的所有记录，但这并不少非做不可的。像我们公司用的几个系统都没有建立。需要删除信息时怎么办呢？写一个宏，来执行多个删除查询就是了。这些见仁见智，看LZ具体情况吧。
2、像LZ这个，个人觉得tblgxgr-id没有存在的必要。一个tblgx和tblgxgr就够了，把后面这个绑定到窗体，而tblgx作为录入的组合框选择就行了。不知道LZ觉得怎么样？

简

roych 发表于 2011-5-26 11:14
1、尽管建立了关系可以级联删除，便于删除相关的所有记录，但这并不少非做不可的。像我们公司用的几个系统都 ...

以前我在论坛上遇到一个朋友，他是不用关系，而且他不用查询，宏，至于查询和宏，他都是用代码来确定，但他也强调，表结构很关键，表结构做好了，后面的设计就做好一半了。

我也不知我是怎么的，老是在关系和用代码确定数据关系中游离不定，总想弄清什么名堂，但又说不清楚我到底想要知道什么。

tblgxgr-id表在该数据库中是显得多余，但我看见很多数据库里，往往选择的是类似tblgxgr-id结构的表，而不是类似tblgxgr结构的表。在该数据库里，我之所以考虑tblgr工人表，是想到工人的排序，比如用工号grid排序。

pq318

首先我觉得有个问题要清楚啊，首先不用关系的后果相信地球人都知道，还有你的编码技术强的话，为何不多用用代码呢，我还是喜欢程序之美

roych

建议LZ还是做下查询吧。毕竟这比写代码直观多了，而且修改起来也更方便。无论怎么说，软件总不会是一劳永逸，而是需要根据实际变化做一些调整的。

aslxt

我建议用关系，表结构规划和关系搞好以后，后面的工作简单得很多。

szyewj

一、内容决定形式；二、表的不可拆分性（避免数据的重复）。因此，一个tblgx和tblgxgr就够了，如图：

szyewj

额，图太小了

szyewj

汗啊，第一次发图，不好意思

todaynew

简 发表于 2011-5-26 10:32
我知道，为了避免数据的重复，实施参照完整性，在数据表里需要采用一对多，一对一等关系，我想了解两个问题 ...

1、无关系不成方圆。但是否在关系视图中建立关系不是最重要的，也就是说除了在关系视图中建立关系外，还可以在查询视图中建立关系，还可以在主子窗体中建立关系，还可以利用筛选建立关系等等。这个都是建立关系的手段和方法，但是不能想象完全没有关系的若干数据表能有什么用处。通常在关系视图中建立表或查询之间的关系是最简单、最直观的，一般来说还是应该利用关系视图来建立表间的关系，定义表间关系的属性。

2、单独的工序与工人建立一个数据表是没什么实际意义的。工序与加工的产品有关系，工人也与加工的产品有关系，也就是说只有存在一个加工任务，工人与工序才能联系起来，所以工人与工序的联系是在有关描述加工的数据表中存在的。
   这种存在可以根据情况出现两种表达方式，最通常的一种表达方式是基于工人所从事的工序是多种，此类情形中，工人和工序的特征字段（也就是ID值或者姓名）需要进入加工表中。另外一种情形是工人的工序岗位完全确定不会变化，这种情形下，工序应该存在与工人表中，也就是说每个工人都只对应一个工序。那么在加工表中只需要工人的特征字段就可以了。

3、以下的示例是基于第一种情形做的表结构设计：




4、在数据库表结构设计时，不应局部的看问题，更不应该割裂出一个局部来讨论全局性的问题。这样的话，永远说不清道不明。工序和工人是两个局部问题，如果没有一个加工任务的话，工序只存在于工艺设计员的设计方案中，工人也只是坐在车间喝茶聊天。这种情况下，工人和工序并不发生什么关系。只有生产任务下达了，工艺的加工图纸到了工人手中，材料齐备、设备启动，工人才会来到钳台或机器旁按照图纸进行他们的工作，工序和工人才发生了关系。这样去观察问题，就有了全局的和实际的视角，数据表的设计也就不是什么难事了。