ERP的物料表结构是怎么设计的

[angular2]

我所在公司是开发企业库存管理软件的。我们的客户属于各个不同的行业，物料结构有很大差异。举例来说，一家纺织行业的公司的物料表有花号字段，另一家生产器材的公司的物料表有形式字段，其他行业还有不同的字段。以上是举例，实际的差异要更大。每次有新项目，都要重新确定字段。为了减少项目的工作量，我们打算编写一个基础版本，但在设计物料表结构时遇到了困难，开发人员不指定怎么设计物料表。目前想到四种可能性：

1，将最常规的字段写在基础版本里，不管行业怎么变，物料名称，物料条码这些字段都是要有的。这个方式仅做了有限度的重用，还是每次都要扩展新的字段。

2，根据已有的经验，尽量大而全的设计物料表。这个方式有两个问题：一是截止目前，新项目总有新东西出现；二是，基础版本里将会出现太多字段，对于特定项目，大部分字段都是无用的，非常累赘。

3，沿用第2点的思路，但是分开不同的行业来做。但是，由于涉及的行业较多，好多项目的行业可能只做一次，很久不会再做第二个项目，想进行有效积累还是比较难。

4，在物料表里写上 10 备用字段，比如 Free1 , Free2, Free 3，数据类型用字符串，每个字段怎么用由项目决定，对单个项目来说，10个字段在数量足够了。这个方式的问题是没有可读性，并且由于没有数据类型，查询性能很差，甚至保存了错误的值也不能发现。

几经讨论后，我们觉得ERP类的程序和我们面临同样的问题，但是开发组没有人熟悉ERP的细节。只好来论坛请教。ERP 到底是怎么解决此类问题的呢？

[以专业开发人员为伍]

引用 6 楼 angular2 的回复:

实际上最大的压力来自老板。老板总是觉得，我们只做库存管理这一块，已经做了那么多项目，可以总结出标准化的东西来。我怀疑他要的是不是一个setup之后配置一下就搞定项目的程序。

传统企业软件的模式化是非常困难的，每一个企业都不一样。任何改进、任何设计，都有被推翻的那一天。所以不要有洁癖，只要务实就好了。没有一定之规，既不能不去搞标准化，也不能盲目地为了搞标准化而劳民伤财过度抽象。

• 打赏
• 举报

回复 赞

[angular2]

引用 12 楼 zbdzjx的回复:

这些字段，大致可分两种： 1、显示用的字段，这种字段，处理起来比较简单，就像你说的，用Free1 , Free2, Free 3，再用一个表来设定这些字段对应哪个名字、类型等等。 2、参与运算、过程等等的字段，这种处理起来就麻烦了，因为有些字段甚至会改变整体的逻辑。所以，通常这些通用软件会分成XX版、YY版……一个行业一个版本，要么就是客户采用一些比较通用化的处理方式，要么就是加钱进行二次开发。 至于SAP，之前听说的，某企业，花了上亿上了SAP，每年还要花数百万进行二次开发。而我之前的那家公司，老板说了：听说SAP很强大，怎么我们要的功能，很多都不能实现，还不如我们自己开发的系统好。

我们的经验是一个行业的不同企业，内部管理也是很大不同。

• 打赏
• 举报

回复 赞

[angular2]

太冷清，其他人没有建议了？

• 打赏
• 举报

回复 赞

[zbdzjx]

这些字段，大致可分两种： 1、显示用的字段，这种字段，处理起来比较简单，就像你说的，用Free1 , Free2, Free 3，再用一个表来设定这些字段对应哪个名字、类型等等。 2、参与运算、过程等等的字段，这种处理起来就麻烦了，因为有些字段甚至会改变整体的逻辑。所以，通常这些通用软件会分成XX版、YY版……一个行业一个版本，要么就是客户采用一些比较通用化的处理方式，要么就是加钱进行二次开发。 至于SAP，之前听说的，某企业，花了上亿上了SAP，每年还要花数百万进行二次开发。而我之前的那家公司，老板说了：听说SAP很强大，怎么我们要的功能，很多都不能实现，还不如我们自己开发的系统好。

• 打赏
• 举报

回复 赞

[以专业开发人员为伍]

从上面的简单例子你可以看出，假设要列出所有的”麻醉药品“的列表，似乎你的ORM系统要自动把3个表组合到一个实体模型上。这就是ORM的含义——编程对象实体定义跟关系数据库具有”模式不匹配“特性，需要数据操作层代码去解决。 假设有一个麻醉药品记录，那么它在对应的”货物“表中的TypeName的值就是“麻醉药品”，而不是“挖掘机“或者“服装”。具体类型记录在最顶层的表中。 假设你列出一些货物的列表，你可以根据每一行数据的类型的不同，而动态加载不同的“展示”或者“编辑”模板。因此TypeName字段非常重要。

• 打赏
• 举报

回复 赞

[烟波钓]

P哥的意思你可能没有理解，我的理解如下： 1.你所说的所有项目的共有字段可以放到一张表里面，看做父表 2.父表中有一个字段TypeName用于标记这条记录应该去哪（几）个子表 3.不用的项目有特殊的字段放到子表中，该表中有主表的ID与主表关联 4.当来了新的项目只需要定义新的TypeName和创建个性化的子表 5.你的ORM层负责主子表之间的关联，例如你查一条记录，ORM自动去匹配主表的记录和需要那个子表的记录

• 打赏
• 举报

回复 赞

[angular2]

引用 16 楼 烟波钓的回复:

P哥的意思你可能没有理解，我的理解如下： 1.你所说的所有项目的共有字段可以放到一张表里面，看做父表 2.父表中有一个字段TypeName用于标记这条记录应该去哪（几）个子表 3.不用的项目有特殊的字段放到子表中，该表中有主表的ID与主表关联 4.当来了新的项目只需要定义新的TypeName和创建个性化的子表 5.你的ORM层负责主子表之间的关联，例如你查一条记录，ORM自动去匹配主表的记录和需要那个子表的记录

p哥的意思我懂。合格orm应该具备映射类层次的能力，实际上，p哥说的是映射类层次的一种策略，将每个子类映射到一张表中。

• 打赏
• 举报

回复 赞

[angular2]

大家早上好。这个提问还是没人关注。

• 打赏
• 举报

回复 赞

[j34jyj94ksigj4j]

完全靠臆想，而且还想设计万能系统，好危险的想法，先不要想着造飞机，先评估一下有没有能力造一个飞机模型

• 打赏
• 举报

回复 赞

[angular2]

引用 18 楼 AndroidJavaApp的回复:

完全靠臆想，而且还想设计万能系统，好危险的想法，先不要想着造飞机，先评估一下有没有能力造一个飞机模型

老板想的：万能程序+应届毕业生=项目款

• 打赏
• 举报

回复 赞

[angular2]

加班 ！

• 打赏
• 举报

回复 赞

[xdashewan]

对于这个问题你要这么看待，不是所有的物料都有花号有形式，就算是纺织行业也不是所有物料都有花号，花号和形式只是不同用户的个性化定制，既然是定制信息，那么这两字段都不该出现在物料表里。然后用户有权利选择定制或者不定制，同样可以选择哪个物料需要定制以及需要定制类型的数量，我并非完全赞同16楼的这个设计方案，当然那也许只是对你的一个提示。这个设计的一个弊端是限制了用户的选择权，当用户的物料完全不需要定制的时候，这个TypeName字段就显得多余。抛开这点再谈谈子表，子表的目的是为了和父表信息一起合成完整的物料信息，看似没问题，但楼主想想，这子表怎么产生由谁来产生，又由谁来维护，每增加一个类型还需要去数据库里增加一张表再设计一些字段吗，还需要我去修改之前的逻辑去添加对那张新表的连接？如果这是一个自用项目，有自己的开发和维护团队，那都不是问题，但如果是商品，那显然变得不合理。所以并不是在物料表里添加TypeName，取而代之是设计一张定制信息表，表中数据由用户通过定制信息界面维护，主要字段是ID和名称。另一张是物料和定制信息的关联，关系为一对多，主要字段是物料ID，定制ID和值。

• 打赏
• 举报

回复 赞

[angular2]

引用 21 楼 xdashewan的回复:

对于这个问题你要这么看待，不是所有的物料都有花号有形式，就算是纺织行业也不是所有物料都有花号，花号和形式只是不同用户的个性化定制，既然是定制信息，那么这两字段都不该出现在物料表里。然后用户有权利选择定制或者不定制，同样可以选择哪个物料需要定制以及需要定制类型的数量，我并非完全赞同16楼的这个设计方案，当然那也许只是对你的一个提示。这个设计的一个弊端是限制了用户的选择权，当用户的物料完全不需要定制的时候，这个TypeName字段就显得多余。抛开这点再谈谈子表，子表的目的是为了和父表信息一起合成完整的物料信息，看似没问题，但楼主想想，这子表怎么产生由谁来产生，又由谁来维护，每增加一个类型还需要去数据库里增加一张表再设计一些字段吗，还需要我去修改之前的逻辑去添加对那张新表的连接？如果这是一个自用项目，有自己的开发和维护团队，那都不是问题，但如果是商品，那显然变得不合理。所以并不是在物料表里添加TypeName，取而代之是设计一张定制信息表，表中数据由用户通过定制信息界面维护，主要字段是ID和名称。另一张是物料和定制信息的关联，关系为一对多，主要字段是物料ID，定制ID和值。

你说的是EAV，这个实际上不好用。

• 打赏
• 举报

回复 赞

[angular2]

这个帖子真是太冷清了

• 打赏
• 举报

回复 赞

[秋的红果实]

引用 21 楼 xdashewan 的回复:

对于这个问题你要这么看待，不是所有的物料都有花号有形式，就算是纺织行业也不是所有物料都有花号，花号和形式只是不同用户的个性化定制，既然是定制信息，那么这两字段都不该出现在物料表里。然后用户有权利选择定制或者不定制，同样可以选择哪个物料需要定制以及需要定制类型的数量，我并非完全赞同16楼的这个设计方案，当然那也许只是对你的一个提示。这个设计的一个弊端是限制了用户的选择权，当用户的物料完全不需要定制的时候，这个TypeName字段就显得多余。抛开这点再谈谈子表，子表的目的是为了和父表信息一起合成完整的物料信息，看似没问题，但楼主想想，这子表怎么产生由谁来产生，又由谁来维护，每增加一个类型还需要去数据库里增加一张表再设计一些字段吗，还需要我去修改之前的逻辑去添加对那张新表的连接？如果这是一个自用项目，有自己的开发和维护团队，那都不是问题，但如果是商品，那显然变得不合理。所以并不是在物料表里添加TypeName，取而代之是设计一张定制信息表，表中数据由用户通过定制信息界面维护，主要字段是ID和名称。另一张是物料和定制信息的关联，关系为一对多，主要字段是物料ID，定制ID和值。

设计一张定制信息表，表中数据由用户通过定制信息界面维护。请问用户如何判断数据类型？用户是不懂计算机的

• 打赏
• 举报

回复 赞

[xdashewan]

引用 24 楼 From_TaiWan 的回复:

设计一张定制信息表，表中数据由用户通过定制信息界面维护。请问用户如何判断数据类型？用户是不懂计算机的

数字，文字，金额，图片，这些通俗易懂的类型用户看不明白吗

• 打赏
• 举报

回复 赞

[ydw_武汉]

根据最小单元进行一层一层向上提取,知道根类.然后分别设置表格来进行处理.

• 打赏
• 举报

回复 赞

[weishaolin13x]

以前我们做化验系统，他们就做了个万能系统， 每种样品有很多检验项，给用户随便定义检验项，可以任意增加删除修改检验项， 包括增加样品，有时间你们可以看看。。。。

• 打赏
• 举报

回复 赞

[weishaolin13x]

用户都有专门的计算机维护人员，交给他们去配置就行了，

• 打赏
• 举报

回复 赞

[weishaolin13x]

我们把增加样品，增加检验项（属性），评级等等，都交给用户去维护，

• 打赏
• 举报

回复 赞