有位前辈曾教我,设计表时,有一个必要的原则是:
“字段是昂贵的,而属性是免费的”
当表中字段很多,报表与报表之间有很多也没有什么必然的联系,也就是你说的这种情况时,可以考虑用属性取代字段
比如:
有字段:A,B,C,D,E,F,G,H,I,J,K,L,M,N
设计一个表,只有两个字段:CodeName, CodeValue
CodeName下填A,B,C,D……这些字段名称,在CodeValue下填写他们相应的值
这样既避免了大量字段造成的数据冗余,又增强了数据库的灵活性。
当然,实际设计时只有CodeName, CodeValue两个字段是不行的,还要填加一些相应的字段以
便于跟其他表的连接,这也需要在数据完整性和数据冗余问题上多考虑一些
我做过一些数据库,遇到这种问题都这么搞
希望对你也有些帮助
“字段是昂贵的,而属性是免费的”
当表中字段很多,报表与报表之间有很多也没有什么必然的联系,也就是你说的这种情况时,可以考虑用属性取代字段
比如:
有字段:A,B,C,D,E,F,G,H,I,J,K,L,M,N
设计一个表,只有两个字段:CodeName, CodeValue
CodeName下填A,B,C,D……这些字段名称,在CodeValue下填写他们相应的值
这样既避免了大量字段造成的数据冗余,又增强了数据库的灵活性。
当然,实际设计时只有CodeName, CodeValue两个字段是不行的,还要填加一些相应的字段以
便于跟其他表的连接,这也需要在数据完整性和数据冗余问题上多考虑一些
我做过一些数据库,遇到这种问题都这么搞
希望对你也有些帮助
设计字段名称的一个原则是易懂,就像写代码时的命名一样,一个字段可以是几个单词的组合,至于采用Camel还是Pascal原则就看个人习惯跟公司的规范了。
例如输出到Excel,输出到Word
方法包括合并单元格\隐藏列\字体大小设置 等等 属性
最后写存储过程将所有业务数据合并成一个 Table 输出
好处多的是
此种方式特别适合各种报表
用户想怎么改就怎么改,只改存储过程
“字段是昂贵的,而属性是免费的”
当表中字段很多,报表与报表之间有很多也没有什么必然的联系,也就是你说的这种情况时,可以考虑用属性取代字段
比如:
有字段:A,B,C,D,E,F,G,H,I,J,K,L,M,N
设计一个表,只有两个字段:CodeName, CodeValue
CodeName下填A,B,C,D……这些字段名称,在CodeValue下填写他们相应的值
这样既避免了大量字段造成的数据冗余,又增强了数据库的灵活性。
当然,实际设计时只有CodeName, CodeValue两个字段是不行的,还要填加一些相应的字段以
便于跟其他表的连接,这也需要在数据完整性和数据冗余问题上多考虑一些
我做过一些数据库,遇到这种问题都这么搞
希望对你也有些帮助
这种做法太土,显然没有关系数据库的概念,完全是凭自己小聪明在做事情,照你这么做,我干脆在数据库里就放一张表字段为TableName,
CodeName, CodeValue,再建一张表描述表的结构,所有的数据都可以放进去了。“字段是昂贵的,而属性是免费的”这个在设计上实际不用考虑,以反映业务为主。
(1)如果后台用存储过程的话,那么数据库中按照将每个单据看成一个对象的原则,存储起来,虽然表可能表较多,但是后面对于报表的修改很有好处。然后,写出通用的报表显示程序,数据库存储过程来提供数据输入,XML文件(存储在数据库中的某个表中或客户端(用于客户个性化的提供))提供报表格式,这样就可以了。
(2)如果不使用存储过程,那就只好使用数据库视图提供事先说明的表连接。另外象121111(和尚下山) 说得,单据上的数据就不能存储为单个metadata,而要使用属性或XML字符串等。
至于数据库的字段命名,我想:如果你实在不能用很好的英语命名,那么用中文也不错。但是
SQL7 会有某些不兼容的情况,而SQL2000没有任何问题,放心使用。
例如输出到Excel,输出到Word
方法包括合并单元格\隐藏列\字体大小设置 等等 属性
最后写存储过程将所有业务数据合并成一个 Table 输出
好处多的是
此种方式特别适合各种报表
用户想怎么改就怎么改,只改存储过程
______________________________________________________________________
BuilderC(ILOVEC++) :我觉得说的不错,不过能否详细点,有没有这方面的文章看看。。
我们可以用实例来讨论问题,举个最简单的例子:关于计算机配置管理的问题
一台计算机有多个部件,如:显示器、cpu、主板、显卡、声卡、键盘、鼠标、软驱、光驱等等,怎么来表示这个关系呢?
您说“‘字段是昂贵的,而属性是免费的’这个在设计上实际不用考虑,以反映业务为主”。那么每一个部件给他一个字段吗?您能列出所有的部件吗?三年前谁知道优盘是什么东东,现在却成了标配,如果您这个数据表是三年前建立的,那现在岂不是又要往里头加个优盘字段,那样的话,修改这个已经存储了三年的数据的表,您觉得很方便吗?
还有一点,如果您有二百台计算机的cpu都是p4,那岂不是要有二百个重复的”P4”, 再多一些呢?多大的数据冗余啊!!!另外,不是每台计算机都包含所有的部件,那您的表中又会有多少空字段啊?
您说“显然没有关系数据库的概念,完全是凭自己小聪明在做事情照你这么做,我干脆在数据库里就放一张表字段为TableName,CodeName, CodeValue,再建一张表描述表的结构,所有的数据都可以放进去了”,那您是否看到“实际设计时只有CodeName, CodeValue两个字段是不行的,还要填加一些相应的字段以便于跟其他表的连接”这句话了呢?您是断章取义了!
还是刚才那个例子,只考虑计算机和部件,其他先放放,我会这样设计:
三个表:Computer, Parts,ComputerParts
Computer表中用一个ComputerID作为主键唯一标志一台计算机
Parts表中用有个字段PartID,PartName。PartID作为主键
计算机和部件显然是个多对多的关系,处理多对多的理想方法当然是要建立一个相互关系表
这里的ComputerParts表就是,有两个字段,ComputerID和PartID,用他们两个来作为主键(考虑到全文索引的需要,也可以另外建立一个代理主键ComputerPartID,而把
ComputerID,PartID作为索引)。
和尚兄认为这样做如何呢?有没有关系数据库的概念呢?还有我加几个数据进去演示一下吗?
上面这个例子只考虑了计算机与部件的关系,没有考虑部件的参数,比如cpu可能是intel的,也可能是AMD的,型号,速度也有不同,但有了前面的例子,想必解决这个问题也不难吧。当然,这种办法肯定也存在它的弊端,也可能比较过时,请各位多多批评指正:)
多值字段是不可避免的,比如A的值有两个:1,2;那就用两行数据表示,codename列都填A, codevalue列一个填1,一个填2,用codename, codevalue作为主键,或自己加一个代理主键
就你刚才说的这个例子来说,是一个树形结构,在ERP中的BOM就是这种结构,这种结构在数据库设计中是经常用到,而恰恰不是象你这样来建立数据表的,从这样角度来说,这是设计的错误,如果来设计的话,我会这样来做
1.设计一个表A来表现不同计算机类型的配置情况,比如它有无显示器、cpu、主板、显卡、声卡、键盘、鼠标、软驱、光驱,这是一个配置树
基本上是结点,父结点的结构。
2.设计一个表B来反映具体的计算机的配置,其配置类型参照A表。它也是一个树结构。
这才是正确的开端。
此外,配置树在会隨着时间不断变化,其中的配件也在不断变化。(如设计工艺,可替换零件等等),具体到应用中还是比较复杂的。
121111(和尚下山)说的有道理.但是自己也承认应用起来很复杂,你说是吗?另外这种做法面临着很大问题,就是关联查询很不方便.另外添加新型设备时,改动很大.
Rayfly(小鸡快跑)的方法是以不变应万变的做法.适合简单项目.
121111(和尚下山)的方法是以变制变的做法.适合复杂项目。
各有千秋,但是用在一般的程序里还是取简洁的方法最好.
可能我没有讲清楚,我说的复杂是指还涉及到计算机设备类型以及其它要素也要有进行范化,等等,实际上,我可以将一个计算机类型一直拆到原器件为止,如东芝笔记本SATELITE1200型的134ks显示屏有内部高压包A32一个,其中有A型元器件3个,B型元器件1个。如果联想昭阳34T型笔记本上想装备134ks显示器时,我只要从SATELITE1200的配置树上将其134ks显示器及其子节点装配过来就行了;这样,当我要查询有多少计算机用了134KS显示器,哪些计算机用了A型元器件都是很方便的。此外我说的复杂还包括了业务的复杂性,象这种的应用,其业务是复杂的,所谓的配置树就是产品设计,它涉及了企业的方方面面。这里还是请有经验的人说说吧。