机械零配件数据库的设计问题

jshecn

to 肥猫
   不是因为属性多，而是不同零部件的属性不一样，这样就不能放在同一表里。
to sclarkca
      分类是可以，但是上万种零部件，他们的属性怎么进行分类，这是一个巨大的工作量。
如果不考虑数据录入的麻烦，用第一种方法只用建一个表。

lodge

不是属性多少的问题, 如果你的处理要使用这些属性(你要使用他们做检索, 做判断)他们对你来说是属性, 如果你没有要用到这些属性的地方, 他们对你来说就是表示用信息, 内容是否相同也就无所谓了
你可以把这些用于表示的信息, 写成一段文字放到数据库里, 表示时则根据文字的格式, 做成相应的表示画面
比如说,
名称|零件1|重量|10G|长度|20 CM

cowherd

最初由 jshecn 发布
[B]to 肥猫
   不是因为属性多，而是不同零部件的属性不一样，这样就不能放在同一表里。
to sclarkca
      分类是可以，但是上万种零部件，他们的属性怎么进行分类，这是一个巨大的工作量。
如果不考虑数据录入的麻烦，用第一种方法只用建一个表。 [/B]

建一个表是绝对不行的，字段的含义对于不同的行意义不同
首先就违反了一般设计原则，其次也太混乱了。

现在有的设备管理系统来看，一般是采取让用户自定义属性
来解决的。

a：定义一系列的单位；
b：定义属性；
c：定义零部件属性。

cowherd

最初由 lodge 发布
[B]不是属性多少的问题, 如果你的处理要使用这些属性(你要使用他们做检索, 做判断)他们对你来说是属性, 如果你没有要用到这些属性的地方, 他们对你来说就是表示用信息, 内容是否相同也就无所谓了
你可以把这些用于表示的信息, 写成一段文字放到数据库里, 表示时则根据文字的格式, 做成相应的表示画面
比如说,
名称|零件1|重量|10G|长度|20 CM [/B]

这样处理我觉得扩展性不好，主要是如何确定他到底
是不是这个检索需要用到的属性，用户其实很多情况
下开始并不知道，或者开始也知道的不全面。

基本定义时这样处理，后来再变就麻烦了。

jshecn

to cowherd
用一个表当然可以，因为客户可能要对属性进行检索。我现在计划用这种最简单的方法：一个属性一条记录。如：零部件编号 ，属性名称，属性值。这样虽然没有了NF，但是这样影响应该不是太大。反正录入人员现在对零部件不熟悉，多练习也好。

cowherd

最初由 jshecn 发布
[B]to cowherd
用一个表当然可以，因为客户可能要对属性进行检索。我现在计划用这种最简单的方法：一个属性一条记录。如：零部件编号 ，属性名称，属性值。这样虽然没有了NF，但是这样影响应该不是太大。反正录入人员现在对零部件不熟悉，多练习也好。 [/B]

我觉得最好还是分得稍微细一点可能要好些。
bom资料嘛，可以分类的地方很多：
属性类别，单位等都是需要的；我觉得把一些单个量度
的定在一起比较好，比如空间尺度的长，宽，高，体积，
重心高等等，电器性能又是一类，放置在多个一对多的表
要比简单的放在一个表中要好得多！