物质系统数据关系结构如下:
1、物质类别
A)房屋建筑类(多项指标)
a.办公用房
b.技术用房(服务站)
c.科研试验用房
d.库房
e.职工宿舍
f.其它房屋建筑
B)家具设备类(按购置价格以价值形式表示)
C)医疗设备类(多项指标)
a.手术及消毒设备
b.辅助诊断设备
c.实验检验设备
d.治疗设备
e.相关设备及用品
D)机械电器类(多项指标)
E)交通运输工具类
a.小汽车
b.大汽车
c.摩托车
F)图书资料类(按购置价格以价值形式表示)
G)其它资产类(按购置价格以价值形式表示)
2、各类物质详细指标
A)房屋建筑
a.名称
b.位置
c.类别(办公用房、技术服务用房等)
d.建筑面积
e.单位价值
f.总价值
g.承建单位
h.竣工时间
i.投入使用时间
j.目前使用状况(a、正在使用;b、闲置)
k.备注
B)家具设备
a.名称
b.购置数量
c.购买单价
d.购买总价
e.购置时间
f.经办人
g.投入使用时间
h.备注
C)医疗设备
a.名称
b.型号
c.类别(手术及消毒设备、辅助诊断设备等)
d.购置时间
e.购买单价
f.购买总价
g.数量
h.经办人
i.投入使用时间
j.使用状况(a、正常使用;b、经常维修,勉强能用;c、不能使用,维修后能用;e、闲置)
k.备注
D)机械电器
a.名称
b.型号
c.购买单价
d.数量
e.总价
f.经办人
g.购置时间
h.投入使用时间
i.使用状况(a、正常使用;b、经常维修,勉强能用;c、不能使用,维修后能用;e、闲置)
j.备注
E)交通运输工具
a.名称
b.型号
c.类别(小汽车、大汽车等)
d.购买数量
e.购买单价
f.购买总价
g.购置时间
h.经办人
i.投入使用时间
j.使用状况使用状况(a、正常使用;b、经常维修,勉强能用;c、不能使用,维修后能用;e、闲置)
k.备注
F)图书资料
a.名称
b.出版商
c.购置数量
d.购买单价
e.购买总价
f.购置时间
g.经办人
h.备注
G)其它资产
a.名称
b.出版商
c.购置数量
d.购买价格
e.购置时间
f.经办人
g.备注我的意思是将各类物质建一个表,这样既结构清晰,访问速度又快,上司的意思要我合并一些表(不是全部,也不可能是全部),比如:将“医疗设备”和“机械电器”共用一表,中间添一“物质类型”字段。理由是表多了不好,并且在编程时要划多个模块(其实只有十几个表,注意是SQL Server7.0)还有:我准备在库中建几个字典表,他要我只建一个,理由是一个字典表好处理一些。说实在的,他的意见无法让我在内心深处真正接受,但由于我刚到这个公司三天,有的话又不好说,只好表面上答应了他的意见。
求各位高手给我一点建议,到底是兄弟我才才疏学浅,还是我上司的意见的问题。
很希望大家的建议。

解决方案 »

  1.   

    i will kill your leader!
      

  2.   

    你既然作了coder,就不要想自己的思路。不要指指点点,这是一些做人的道理。我不需要看那个结构,我给你说的是良言。请你记住。
      

  3.   

    感谢: pengdali(大力 V2.0)
      

  4.   

    to:seeder(seeder
    你是第一个和我一样想法的人哟,不知道这种想法对不对!!
    敬请大家继续发言
      

  5.   

    http://expert.csdn.net/Expert/TopicView1.asp?id=2058762请帮忙看看这个贴子...性质也是差不多的..我比较赞同合并在尽量少的库或表中,我是新手..
      

  6.   

    我同意 pengdali(大力 V2.0)的看法,是否需要合并表取决于表的结构。至于字典表,我认为还是分开的好!
      

  7.   

    pengdali(大力 V2.0)分析在理
      

  8.   

    有没有搞错???谁说的表越简单越好?有没有做过大型数据库项目?有没有考虑到海量记录后的冗余和速度?对于一个数据表,字段越简洁性能越高!
    倘若两个表结构不一样,当然分开好!如果有一些差异,还是分开好!只要两个表的结构不完全一样,不用考虑去合并,因为会对你你以后的编程和扩展带来很多麻烦。
    当然,可以考虑pengdali(大力 V2.0)的做法!
      

  9.   

    赞同lonaerd(罗纳尔多) 的看法,
      

  10.   

    我们现在的工作是coder,我想我们还是先作好这个吧
      

  11.   

    对了,春哥,最近积分如何?好象你我几乎同时到csdn的,我快3个月了,升星还没什么眉目,你的如何了?
      

  12.   

    我想問題不在於此。
    開發一個系統無論是mis,mrp,erp
    在用戶的角度只是為了簡便,易用,能解決問題
    關於你和你上司意見有分岐的事情
    你要主動發表你自己的看法,和他們多交流
    也要聽你的直接負責人的話(我說的直接負責是(技術總監))
    在技術上他是權衡
      

  13.   

    还是你们经理的比较好。
    分析12
        1.现在类别是完全可知的,如果不可知,照你的方法做的话要是新增一个类别就会要新增数据表,而新增数据表会对程序的编写造成较大的因难,针对于某个表需要专门处理。
        2.数据字典当然是越少越好,这样条件分支会减少到最少,而照你的意思,会有很多问题。我不知道你是否做过很长时间的数据库程序设计,但你的方法在数据库程序设计中是不太成熟的。你重速度没错,但系统完成后的修改工作就会让你受不了。所以有时是要牺牲一些个人想法的。如果你看过如鼎新WorkFlow ERP或是SAP的系统,可能你就不会这样想了。