這個表怎么設計呀

lodge

最初由 ccwlm741212 发布
[B]

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

咱的软件骗了十年, 每年都有一千万

矛以

Jacky兄台，假定您们公司是做陶瓷的。而您的目标，

• 1>。 是要纪录公司所有陶瓷产品的特性。
  如产品的名称，序号，编号，高度，重量，颜色，干度，湿度，长度，色泽等等。
• 2>。 并能够把产品的数据，横列的显示在窗口界面上。
  

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

谁是Primary Key？[/COLOR]

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

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

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

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



- 矛以

jackyzhung

我是做紡織的,这个系统要在几家公司里用,所以用编码表灵活些﹐
不过基本数据表和编码表怎幺交叉各位老大能不能
说的具体一点,小弟不会﹐多谢!

lodge

恩, 既然你坚持使用代码表, 你的概念应该是这样
你有两个实体:
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

最初由 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]

咱就是这意思

lodge

最初由 ccwlm741212 发布
[B]

咱就是这意思
[/B]

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

ccwlm741212

最初由 lodge 发布
[B]

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

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

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

lodge

最初由 ccwlm741212 发布
[B]

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

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

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

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

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

ccwlm741212

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

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

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

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

lodge

最初由 ccwlm741212 发布
[B]

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

哦, 看来偶的表达能力太低下了,