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

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

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

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

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

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

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

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