关于SQL7.0的问题

[dqj]

表:顾客
顾客ID 姓名 身份证地址 通信地址 销售日期 销售门市 售货凭证号 联系电话
在一些书上这样不符合标准,有冗余,比如 销售日期 销售门市 售货凭证号三个字段可以从另一个表销售得到
联系电话顾客有的有一个号码,有的有二个,甚至三个,所以联系电话可在另一个表中


折分后如下:
表:销售
销售ID 曰期 门市 售货凭证号 商品编码 数量 单价

表:顾客
顾客ID 姓名 身份证地址 通信地址 销售ID

表:联系电话
顾客ID 员工ID 往来单位ID 电话号码 传呼 传真
表:员工
员工ID 姓名 身份证地址 通信地址 文化程度 推荐人 工作时间 辞职时间
表:往来单位
往来单位ID 单位简介 联系人
表:编码
商品编码 商品名称 商品简介

关系
表:编码 表:销售
商品编码-----商品编码 表:顾客 表:联系电话
销售ID-----销售ID
顾客ID-------顾客ID 表:员工
员工ID--------员工ID 表:往来单位
往来单位ID-----------------往来单位ID
1.这样建表对不对?如果以后有仕么变化,如增加字段或减少字段,对数据的连续性有无影响?
2.表:联系电话 有大量的空值,如录入顾客ID,则员工ID和往来单位ID必是空值,丕有有电话的
不一定有传呼,有传真的不一定有手机,必然会有空值,
3.数据库SQL7.0,表:销售和表:顾客大约十万行记录,如果表分得很细,一个查询会联接许多表,是
否影响性能?

[Axiong]

1.因为设计时不可能完全按第三范式。所以说不上不对。但你的顾客表不应该要销售ID，这可能会错误。你不可能有一个销售ID就要添加一条记录。应该在销售表中增加顾客ID，因为每一个销售ID一定对应一个顾客。在sql70中增加和减少字段不影响其他数据，当然你的数据一定要满足限制。
2.其实这只是个空间的问题。如果你要记载这么多信息，就没办法了。关键是你要怎么用。
3.分的太细，肯定会影响查询性能。一般三个以下的关联速度还可以。多于三个就有点慢了。这只是我的经验。

[Axiong]

其实你这个问题只要能保证你的系统能正常处理就行了。因为它不规范。所以就不必太追求性能和容量了。

[dqj]

按照这个例子,怎么样才是规范的?因为我担心以后不得不重来或更改,整个库大约有二十多个表

[dqj]

是这样的,有一个销售id不一定有顾客id,只有部分顾客需要进入顾客
表,在关系中顾客id是一方,销售id是多方.还有和我的录入顺序有关,
.因为在录入销售时不知道顾客ID.
销售ID和顾客ID都是自动编号.录入程序是一个人先录入表:销售,
另一人稍后在另一微机上录入表:顾客.再解释一下,录表:销售的人
通过销售单录入,录表:顾客的人通过顾客登记表录入,在顾客登记表
上有售货凭证号,查找表:销售的售货凭证号,找到销售ID,再录入.但
是售货凭证号不是唯一的,录入员可以给合表:销售的售货凭证号和商
品编码确定唯一.

[Axiong]

二十来个表就怕？况且你就只有几个是关键的。放心了。
你的整个处理也不是太复杂，重来也很快的。

[huitor]

进行数据库设计时，一般遵循第三范式，但也不必强求。有时为了性能可作适当冗余。

[blue]

在涉及到数据库的软件开发，据本人的经验，数据库结构是最重要的，所以在设计阶段
最好能对数据库的各个表、视图、存储过程等数据库端的对象规划好，作比较深远些的
考虑，以免....(这与你的所有的数据库事务处理流程有关).

[XiaoYang]

一开始的设计不可能做到完美,如果你能在系统做完时发现数据库运行正常已经相当不错了.