Chinaunix

标题: 這個表怎么設計呀 [打印本页]
作者: jackyzhung    时间: 2003-12-12 20:35
标题: 這個表怎么設計呀
各位大虾好

一个表prod(产品表)大体上有这几个字段:
ID,Code,name,height,weigh,color,dry
序号﹐编号﹐名称﹐高度﹐重量﹐颜色﹐干度

因为\"高度\"﹐\"重量\",\"颜色\"和\"干度\"﹐这几个参数是不固定的
有是会多几个﹐或是减几个﹐
我现在是把它们单独拿出来做成这样子

prod(产品表)
prod_id,code,name
union(关联表)
union_id,prod_id,req_id,value
req(工艺表)
req_id,req_name

这样是可以解决参数不固定的问韪
不过显示在窗口界面上就不能放成横着的一排了
像这个样子
序号 编号  名称    高度 重量  颜色  干度
001   01       针织布    10     20       blue      10
002   02       纱布      16     20        red       10

各位大虾怎幺做才能既解决参数不固定又能放成
横着的一排呢
作者: ccwlm741212    时间: 2003-12-12 22:18
因为\"高度\"﹐\"重量\",\"颜色\"和\"干度\"﹐这几个参数是不固定的 ?   

--不懂
作者: jackyzhung    时间: 2003-12-12 22:39
就是说 参数的个数不是固定 (prod 产品表的字段数是不固定)
还可以加上很多个﹐比如﹐现在加上﹐湿度﹐长度﹐色泽﹐
现在就成了湿度﹐长度﹐色泽﹐高度﹐重量﹐颜色﹐干度﹐
也有些产品不要”颜色”的﹐那幺颜色这个字段是不要的了
作者: ccwlm741212    时间: 2003-12-12 22:53
按照数据库设计的原理来说分2个表
1、基本数据表
2、属性编码库（湿度﹐长度﹐色泽。。。）
3、1-2做交叉表（本人感觉：这个交叉表没多大实际意义，平面的也可以的）
作者: lodge    时间: 2003-12-12 23:26
想法那么复杂, 把可能的属性都列出来做字段, 并允许它们为空, 不就完了?
做表之前, 要搞清楚自己有哪些实体, 该实体有哪些属性, 和如何使用这些属性来完成对实体的查寻处理
你这么设计表, 写SQL的时候不晕倒才怪
作者: ccwlm741212    时间: 2003-12-12 23:43
最初由 lodge 发布
[B]想法那么复杂, 把可能的属性都列出来做字段, 并允许它们为空, 不就完了?
[/B]


咱的HIS系统是这样设计，ERP这样的大系统这样做是很被动滴:灵活性
作者: magicangel    时间: 2003-12-13 00:10
最初由 lodge 发布
[B]想法那么复杂, 把可能的属性都列出来做字段, 并允许它们为空, 不就完了? [/B]



小系统还是这样比较简单省事，以后维护起来也方便，只是冗余太多。大系统还是要编码表的，好的编码灵活性强，当然维护起来也比较复杂。
作者: lodge    时间: 2003-12-13 00:28
最初由 magicangel 发布
[B]


小系统还是这样比较简单省事，以后维护起来也方便，只是冗余太多。大系统还是要编码表的，好的编码灵活性强，当然维护起来也比较复杂。 [/B]

这不是简单和省事的问题而是效率问题, 如果产品表有几十万件数据, 每次检索都要先和属性表结合, 那就很成问题了, 特别是楼主的用例已经表明, 所有属性都可以被任何实体使用, 这不能不是考虑问题的出发点.

冗余的问题偶是不以为然的, 冗余是指相同的实体被多条记录重复使用, 当实体内容发生变化时, 就会产生数据整合性被破坏的问题. 这里, 所谓实体只是属性名和属性值的问题而已, 不存在可能破坏整合性的问题.
当然, 如果这不是一个专用系统的话, 因属性无法预先确定, 只好使用属性表来保证灵活性, 这是无可奈何的选择, 不过楼主的系统似乎很专一, 灵活性应该不是关键问题吧.
心情不爽说话较冲, 见谅见谅
:rolleyes:
作者: omencathay    时间: 2003-12-13 00:30
如果属性参差不齐，数据量不是很大，干脆不用考虑严格的关系问题，直接按照属性最多的，在表里多加几个字段的了，空的默认成null
作者: omencathay    时间: 2003-12-13 00:32
比如高度1、高度2，。。。
作者: ccwlm741212    时间: 2003-12-13 00:39
最初由 omencathay 发布
[B]如果属性参差不齐，数据量不是很大，干脆不用考虑严格的关系问题，直接按照属性最多的，在表里多加几个字段的了，空的默认成null [/B]


这是比较简单的处理方法，10左右可以考虑，否则麻烦了哦，毕竟考虑的不只是这几个属性的维护
作者: lodge    时间: 2003-12-13 00:45
最初由 ccwlm741212 发布
[B]

这是比较简单的处理方法，10左右可以考虑，否则麻烦了哦，毕竟考虑的不只是这几个属性的维护 [/B]

问题在于属性的维护倒底是做什么, 一个部件的尺寸有必要和别的物件共有吗? 如果不是要经常性修改共同的属性, 属性的多少也就不是问题了.
如果系统中不是要不断增加新属性的话, 使用属性表来管理属性就没有太大的必要了
作者: ccwlm741212    时间: 2003-12-13 00:50
最初由 lodge 发布
[B]
问题在于属性的维护倒底是做什么, 一个部件的尺寸有必要和别的物件共有吗? 如果不是要经常性修改共同的属性, 属性的多少也就不是问题了.
如果系统中不是要不断增加新属性的话, 使用属性表来管理属性就没有太大的必要了 [/B]


那究竟给用户留多少算合适呢？今天是20个，1年后需要25个呢，2年后需要30个呢。。。。而这样的变动所影响的系统数据和报表统计有多少你衡量过没有，而且这样的工作企业的人员能解决吗
作者: lodge    时间: 2003-12-13 00:56
最初由 ccwlm741212 发布
[B]

那究竟给用户留多少算合适呢？今天是20个，1年后需要25个呢，2年后需要30个呢。。。。而这样的变动所影响的系统数据和报表统计有多少你衡量过没有，而且这样的工作企业的人员能解决吗 [/B]

楼主不是在开发SAP或者ORACLE这样的通用系统, 他是在为一个公司做专用系统, 所需要的属性是完全可以通过调查用户需求来得到的. 要知道, 为了保证灵活性, 是要付出代价的, 工时和成本都要上升的.
作者: omencathay    时间: 2003-12-13 00:57
最初由 ccwlm741212 发布
[B]

那究竟给用户留多少算合适呢？今天是20个，1年后需要25个呢，2年后需要30个呢。。。。而这样的变动所影响的系统数据和报表统计有多少你衡量过没有，而且这样的工作企业的人员能解决吗 [/B]


大不了重新设计表，然后把原有的数据DTS进去
作者: ccwlm741212    时间: 2003-12-13 01:01
最初由 lodge 发布
[B]
楼主不是在开发SAP或者ORACLE这样的通用系统, 他是在为一个公司做专用系统, 所需要的属性是完全可以通过调查用户需求来得到的. 要知道, 为了保证灵活性, 是要付出代价的, 工时和成本都要上升的. [/B]


这位兄弟可是在纺织行业的ERP哦，

即使是专用系统，这样做也是不负责责任的表现，既然属性不定，我们的软件系统设计就应该考虑这样的不确定因数所带来的结果，特别是如果要推广的话，修改的工作量将是很大很大的
作者: ccwlm741212    时间: 2003-12-13 01:02
最初由 omencathay 发布
[B]

大不了重新设计表，然后把原有的数据DTS进去 [/B]


所有的报表和统计呢，重新设计一下
作者: lodge    时间: 2003-12-13 01:10
最初由 ccwlm741212 发布
[B]

这位兄弟可是在纺织行业的ERP哦，

即使是专用系统，这样做也是不负责责任的表现，既然属性不定，我们的软件系统设计就应该考虑这样的不确定因数所带来的结果，特别是如果要推广的话，修改的工作量将是很大很大的 [/B]

NO NO NO NO
怎么是不负责任呢, 把用户的每一分钱都花在他感兴趣的地方, 偶这几天正是为这样的问题烦恼, 偶是在做服装业ERP, 用户只许偶们使用色码标三个属性, 偶们不是一样也要做下来嘛, 不是每一个属性都是那么有用滴, 属性越少越通俗越容易推广的说
作者: omencathay    时间: 2003-12-13 01:11
最初由 ccwlm741212 发布
[B]

所有的报表和统计呢，重新设计一下 [/B]


这倒没有考虑:terrible:
作者: ccwlm741212    时间: 2003-12-13 01:13
最初由 lodge 发布
[B]
NO NO NO NO
怎么是不负责任呢, 把用户的每一分钱都花在他感兴趣的地方, 偶这几天正是为这样的问题烦恼, 偶是在做服装业ERP, 用户只许偶们使用色码标三个属性, 偶们不是一样也要做下来嘛, 不是每一个属性都是那么有用滴, 属性越少越通俗越容易推广的说 [/B]


咱和你一样曾经也是这样做滴！一个库存软件骗了5万,可要想继续推广，咱下一没这样做
作者: lodge    时间: 2003-12-13 02:17
最初由 ccwlm741212 发布
[B]

咱和你一样曾经也是这样做滴！一个库存软件骗了5万,可要想继续推广，咱下一没这样做 [/B]


咱的软件骗了十年, 每年都有一千万
作者: 矛以    时间: 2003-12-13 04:21
Jacky兄台，假定您们公司是做陶瓷的。而您的目标，


那建表的第一个问题，我觉得是Normalization，

谁是Primary Key？[/COLOR]

因为高度，重量，颜色，干度，湿度，长度，色泽是可有可无的，所以不能成Primary
Key。又假定陶瓷产品名称一定要有，但同一陶瓷产品名称，却可能有不同的高度，
重量，颜色。所以也不能成Primary Key。

序号，编号应是可行的Primary Key，因为每个陶瓷产品，都有序号和编号，是独立
而不重复的，所以能够充分表达每个陶瓷产品。

您可以看见，“参数不固定”的问题，不是Relational Model数据库Normalization设
计上的难题，因为在选Primary Key时，就解决了！

它的问题，是数据处存，查寻处理的执行的效率。
Lodge 和菜刀的方法，是解决执行效率，最便当的好方法。
就是把“参数不固定”，用空值表达不存在的产品特性！



- 矛以
作者: jackyzhung    时间: 2003-12-13 09:05
我是做紡織的,这个系统要在几家公司里用,所以用编码表灵活些﹐
不过基本数据表和编码表怎幺交叉各位老大能不能
说的具体一点,小弟不会﹐多谢!
作者: lodge    时间: 2003-12-13 09:42
恩, 既然你坚持使用代码表, 你的概念应该是这样
你有两个实体:
1.产品(产品编号(PK), 名称.....)
2.属性(属性编号(PK), 属性名称, 表示列号....)
由于产品和属性是多对多的关系(偶很讨厌这种关系, 它会对将来的查询处理带来很多麻烦)
因此你需要建立一个关系表, 也就是所谓的交叉表
3. 产品属性表(产品编号(FK), 属性编号(FK), 属性值.....)
现在考虑一下如何产生你想要得到的视图:

序号 编号 名称 高度 重量 颜色 干度
001 01 针织布 10 20 blue 10
002 02 纱布 16 20 red 10

你需要完成以下工作
1.        取出属性列表, 按照表示列号生成第一行
2.        取出各产品的所有属性和表示列号
3.        列产品表将属性值放到对应的列里去
上面是一个处理的基本手续, 在实现的时候, 有可能使用交叉结合(CROSSTAB, CCW应该对这个很熟) 用一句SQL文实现, 或者使用SP(偶觉的更加简单易懂), 再或者用外部程序实现也可以.
作者: ccwlm741212    时间: 2003-12-13 20:16
最初由 lodge 发布
[B]恩, 既然你坚持使用代码表, 你的概念应该是这样
你有两个实体:
1.产品(产品编号(PK), 名称.....)
2.属性(属性编号(PK), 属性名称, 表示列号....)
由于产品和属性是多对多的关系(偶很讨厌这种关系, 它会对将来的查询处理带来很多麻烦)
因此你需要建立一个关系表, 也就是所谓的交叉表
3. 产品属性表(产品编号(FK), 属性编号(FK), 属性值.....)
现在考虑一下如何产生你想要得到的视图:

序号 编号 名称 高度 重量 颜色 干度
001 01 针织布 10 20 blue 10
002 02 纱布 16 20 red 10

你需要完成以下工作
1.        取出属性列表, 按照表示列号生成第一行
2.        取出各产品的所有属性和表示列号
3.        列产品表将属性值放到对应的列里去
上面是一个处理的基本手续, 在实现的时候, 有可能使用交叉结合(CROSSTAB, CCW应该对这个很熟) 用一句SQL文实现, 或者使用SP(偶觉的更加简单易懂), 再或者用外部程序实现也可以. [/B]


咱就是这意思
:right:
作者: lodge    时间: 2003-12-13 22:24
最初由 ccwlm741212 发布
[B]

咱就是这意思
:right: [/B]


咳咳, 虽然得到了认同, 但偶仍然鄙视这个方案.
在偶看来, 该做法是不符合常规的, 虽然在逻辑上行得通, 但是由于公司的业务逻辑中一般没有所谓动态属性管理一项, 此举将给整个系统的处理逻辑带来许多不可预计的问题. 至少, 由谁来管理这个属性表本身就是个问题, 显然在这个问题上, 该系统不但没有减少企业的工作反而增加了企业的管理工作.
也许有人会说在SAP等知名系统中这种做法是很常见的, 但请不要忘记, SAP系统的实施是需要专业公司来完成的, 换句话说用户根本不需要维护它的属性表.
:p :p :p
作者: ccwlm741212    时间: 2003-12-13 22:48
最初由 lodge 发布
[B]

咳咳, 虽然得到了认同, 但偶仍然鄙视这个方案.
在偶看来, 该做法是不符合常规的, 虽然在逻辑上行得通, 但是由于公司的业务逻辑中一般没有所谓动态属性管理一项, 此举将给整个系统的处理逻辑带来许多不可预计的问题. 至少, 由谁来管理这个属性表本身就是个问题, 显然在这个问题上, 该系统不但没有减少企业的工作反而增加了企业的管理工作.
也许有人会说在SAP等知名系统中这种做法是很常见的, 但请不要忘记, SAP系统的实施是需要专业公司来完成的, 换句话说用户根本不需要维护它的属性表.
:p :p :p [/B]


在软件设计的过程中，该不该，合适不合适，有时候很难去评价和实施，速度、时间、空间、复杂性、工作量、专业性、简单性我们都必须去面对，可总有一个取舍和选择的过程！每个人都可以选择和坚持这样的选择，可有一点：必须为用户解决问题，得到准确的数据，至于选择怎样的设计思路，没人能说自己是最好的，只有用户才有权利说。

SAP设计和使用很复杂，可是最好的ERP，这是用户们说的
作者: lodge    时间: 2003-12-13 23:25
最初由 ccwlm741212 发布
[B]

在软件设计的过程中，该不该，合适不合适，有时候很难去评价和实施，速度、时间、空间、复杂性、工作量、专业性、简单性我们都必须去面对，可总有一个取舍和选择的过程！每个人都可以选择和坚持这样的选择，可有一点：必须为用户解决问题，得到准确的数据，至于选择怎样的设计思路，没人能说自己是最好的，只有用户才有权利说。

SAP设计和使用很复杂，可是最好的ERP，这是用户们说的 [/B]

恩, 原则是正确的, 但问题在于思考方法上, 当一个系统的处理逻辑上出现了和用户的业务逻辑不付的情况时, 需特别谨慎, 如这个贴子中的属性表, 虽然它解决了产品属性编制逻辑的问题, 但是它同时增加了新的用户使用逻辑, 该逻辑是否能符合用户的要求是无法判别的, 因为用户自己也不知道. 这是一个凭空多出来的东西, 不是吗?

别怪偶在这个问题上犯贫, 在ERP版块上见过很多朋友关于企业要接受新的理念来适应ERP系统的讨论, 实际上, 很多都是由于系统中凭空多了个原本没人关心的业务而堂而皇之的把这项新业务变成了新理念的.

举个例子吧, 就拿上面的的产品表来说, 这个表应该是必不可少的, 但是不知道你发现没有, 实际上公司里只有供销部门在使用和管理这个表, 而财务的成本核算等都是通过原始凭证来处理的. 如果建立产品表, 并使产品表和库存表, 凭证表发生关系, 就会要求财务在记帐时如果发现物料价格变更或新物料时必须及时修改产品表, 这样不知不觉产品表的维护就变成了财务的工作了, 于是组织结构的相应调整就成为在所难免的事(比如, 产品购入时要经过供销部门审核之类原先并不需要的手续等等). 因此, 如果单纯从系统处理的概念上来考虑对某个方案进行取舍, 是很难和实际情况相吻合的, 最好方法是严格按照实际业务逻辑进行设计, 如不为产品表和库存表建立关系, 并允许大量冗余存在等等.
作者: ccwlm741212    时间: 2003-12-13 23:39
最初由 lodge 发布
[B]
恩, 原则是正确的, 但问题在于思考方法上, 当一个系统的处理逻辑上出现了和用户的业务逻辑不付的情况时, 需特别谨慎, 如这个贴子中的属性表, 虽然它解决了产品属性编制逻辑的问题, 但是它同时增加了新的用户使用逻辑, 该逻辑是否能符合用户的要求是无法判别的, 因为用户自己也不知道. 这是一个凭空多出来的东西, 不是吗?

别怪偶在这个问题上犯贫, 在ERP版块上见过很多朋友关于企业要接受新的理念来适应ERP系统的讨论, 实际上, 很多都是由于系统中凭空多了个原本没人关心的业务而堂而皇之的把这项新业务变成了新理念的.

举个例子吧, 就拿上面的的产品表来说, 这个表应该是必不可少的, 但是不知道你发现没有, 实际上公司里只有供销部门在使用和管理这个表, 而财务的成本核算等都是通过原始凭证来处理的. 如果建立产品表, 并使产品表和库存表, 凭证表发生关系, 就会要求财务在记帐时如果发现物料价格变更或新物料时必须及时修改产品表, 这样不知不觉产品表的维护就变成了财务的工作了, 于是组织结构的相应调整就成为在所难免的事(比如, 产品购入时要经过供销部门审核之类原先并不需要的手续等等). 因此, 如果单纯从系统处理的概念上来考虑对某个方案进行取舍, 是很难和实际情况相吻合的, 最好方法是严格按照实际业务逻辑进行设计, 如不为产品表和库存表建立关系, 并允许大量冗余存在等等. [/B]


其实我们这个帖子讨论的核心是：是让开发商不断维护产品属性还是让用户自己去维护产品属性？ 是吗？ 如果是的，其实答案应该不难
作者: lodge    时间: 2003-12-13 23:53
最初由 ccwlm741212 发布
[B]

其实我们这个帖子讨论的核心是：是让开发商不断维护产品属性还是让用户自己去维护产品属性？ 是吗？ 如果是的，其实答案应该不难 [/B]


哦, 看来偶的表达能力太低下了, :shy2: :shy2:
作者: ccwlm741212    时间: 2003-12-13 23:57
最初由 lodge 发布
[B]

哦, 看来偶的表达能力太低下了, :shy2: :shy2: [/B]


故事才刚刚开始呢
作者: magicangel    时间: 2003-12-17 04:12
最初由 lodge 发布
[B]
冗余的问题偶是不以为然的, 冗余是指相同的实体被多条记录重复使用, 当实体内容发生变化时, 就会产生数据整合性被破坏的问题. 这里, 所谓实体只是属性名和属性值的问题而已, 不存在可能破坏整合性的问题.
:rolleyes: [/B]


我个人认为空值也是一种冗余。而且为了减少对已有查询或报表的维护和可能的影响，建议尽量少使用空值。对查询和数据修改语句进行规划，使空值的影响降到最小。冗余和完整性没有必然的联系。
作者: yining    时间: 2003-12-17 04:42
前面不是说了么？关键是要看用户的要求。允许空值的做法很简单，对象模型也比较好处理。但是主要的缺点是以后没有办法比较方便的扩充属性。这个对于成熟的企业（有相对固定的产品）不存在问题，或者问题很小。但是如果是一个变动比较大的行业，或者是新企业（产品还没有确定），则非常不适合。归根结底，设计是要看具体的需求的。

根据一般的经验，如果客户也不是很确定的话，选择属性名称和属性对应的列表的方式比空值要好一些。这样的应用有较大的弹性，即使日后用户需要更改属性，还是有余地的。

另外，多种产品属性的对齐也可以在业务逻辑中进行呀，不见的对速度的影响会有多大。但是这种方法可能会引起的麻烦是属性的查询必须通过属性名称，不太直观。
作者: yining    时间: 2003-12-17 04:44
最初由 magicangel 发布
[B]

我个人认为空值也是一种冗余。而且为了减少对已有查询或报表的维护和可能的影响，建议尽量少使用空值。对查询和数据修改语句进行规划，使空值的影响降到最小。冗余和完整性没有必然的联系。 [/B]


如果是相对固定的产品，允许空值的设计不应该对查询/维护产生太大影响吧？如果更多的情况下是只读操作的话，用LDAP吧。
作者: magicangel    时间: 2003-12-17 04:49
最初由 yining 发布
[B]

如果是相对固定的产品，允许空值的设计不应该对查询/维护产生太大影响吧？如果更多的情况下是只读操作的话，用LDAP吧。 [/B]


我引用的是微软的官方原话。
作者: magicangel    时间: 2003-12-17 04:49
这段：

而且为了减少对已有查询或报表的维护和可能的影响，建议尽量少使用空值。对查询和数据修改语句进行规划，使空值的影响降到最小。



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2