這個表怎么設計呀

ccwlm741212

最初由 omencathay 发布
[B]如果属性参差不齐，数据量不是很大，干脆不用考虑严格的关系问题，直接按照属性最多的，在表里多加几个字段的了，空的默认成null [/B]

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

lodge

最初由 ccwlm741212 发布
[B]

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

问题在于属性的维护倒底是做什么, 一个部件的尺寸有必要和别的物件共有吗? 如果不是要经常性修改共同的属性, 属性的多少也就不是问题了.
如果系统中不是要不断增加新属性的话, 使用属性表来管理属性就没有太大的必要了

ccwlm741212

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

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

lodge

最初由 ccwlm741212 发布
[B]

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

楼主不是在开发SAP或者ORACLE这样的通用系统, 他是在为一个公司做专用系统, 所需要的属性是完全可以通过调查用户需求来得到的. 要知道, 为了保证灵活性, 是要付出代价的, 工时和成本都要上升的.

omencathay

最初由 ccwlm741212 发布
[B]

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

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

ccwlm741212

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

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

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

ccwlm741212

最初由 omencathay 发布
[B]

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

所有的报表和统计呢，重新设计一下

lodge

最初由 ccwlm741212 发布
[B]

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

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

NO NO NO NO
怎么是不负责任呢, 把用户的每一分钱都花在他感兴趣的地方, 偶这几天正是为这样的问题烦恼, 偶是在做服装业ERP, 用户只许偶们使用色码标三个属性, 偶们不是一样也要做下来嘛, 不是每一个属性都是那么有用滴, 属性越少越通俗越容易推广的说

omencathay

最初由 ccwlm741212 发布
[B]

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

这倒没有考虑:terrible:

ccwlm741212

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

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