school 表 SCID、name、xxx 其他属性 studio 表 STID, name , xxx其他属性 article表 AID,title, content articleType表 AID,type(学校或工作室标识),SCID或STIC(前提这两个字段类型一致)其实怎么设计具体还得看你的需要,考虑各方面,比如是查询多还是修改多
IndustryTypes id name xxxxxxxxxxxxxxxxxxxxx 1 工作室 2 学校 Industry id typeid name xxxxxxxxxxxxxxxxxxxxx 1 1 工作室A 2 2 学校Aarticle id industryid xxxxxxxxxxxxxxxxxxxxx 1 1 2 1 3 2
从数据库层面来讲,这么做是个不错的方案,如果项目使用了ORM类的框架,比如HIBERNATE就不太好搞了,ID对象的是一个对象,两个不同的对象不能共用一个ID字段1.java端是不是可以不用many to one之类的关系维护,只用个long或int 的id属性 2.你确实要用many to one之类的关联的话,是不是用个抽象类作关联对象,然后school、studio对象都继承此抽象类 (或者接口)
studio 表 STID, name , xxx其他属性
article表 AID,title, content, ID(学校 / 工作室标识),type(区分学校,工作室: 0:学校 1:工作室)
从数据库层面来讲,这么做是个不错的方案,如果项目使用了ORM类的框架,比如HIBERNATE就不太好搞了,ID对象的是一个对象,两个不同的对象不能共用一个ID字段
问题就出在这里,如果 學校,工作室共同一张表,就出了另一个问题了, 学校,工作室有很多不同的属性,比如学校可能会有logo,校长等,而工作室对应的可能会有一些“标签”等啥字段,跟学校完全不一样,如果这两个合并那不是又出现字段冗余了
studio 表 STID, name , xxx其他属性
article表 AID,title, content
articleType表 AID,type(学校或工作室标识),SCID或STIC(前提这两个字段类型一致)其实怎么设计具体还得看你的需要,考虑各方面,比如是查询多还是修改多
1 工作室
2 学校
Industry id typeid name xxxxxxxxxxxxxxxxxxxxx
1 1 工作室A
2 2 学校Aarticle id industryid xxxxxxxxxxxxxxxxxxxxx
1 1
2 1
3 2
从数据库层面来讲,这么做是个不错的方案,如果项目使用了ORM类的框架,比如HIBERNATE就不太好搞了,ID对象的是一个对象,两个不同的对象不能共用一个ID字段1.java端是不是可以不用many to one之类的关系维护,只用个long或int 的id属性
2.你确实要用many to one之类的关联的话,是不是用个抽象类作关联对象,然后school、studio对象都继承此抽象类
(或者接口)
在LZ给出的方案中可能需要扩展多张表
所以设计三张张表机构organization,文章artice,以及organization_artice对应关系表,学校和工作室只是其中机构的子类而已
人可以属于学校,同时也可以属于工作室, 而现在的要求就是这个文章要区分是学校的,还是工作室的,所以没办法从人员表上面做操作,我就直接没把人员表写出来了根据楼主的需求,完全可以只用文章表、人员表。
文章表里多添加一个字段用来区分学校和工作室(如:添加一个Long类型的字段,0表示学校、1表示工作室)
方案1太局限了,以后要是还有一个角色可以写文章呢!!
方案3 文章表弄成了2个表,这不符合设计,既然是文章为何要分开?方案2 有更好的扩展,以后又其他的角色写文章,比如还有老师,只需添加教师表和教师与文章关联表
当然你也可以将文章中加一个Type,通过Type来区分是那个角色的文章
文章表:人id
看你的需求,应该学校与工作室的属性差别很大,建议如下方式
机构表:类型(学校、工作室)
学校表:机构id(主键)
工作室表:机构id(主键)查学校相关时,学校表为主表,查工作室时工作室表为主表,统计时机构表为主表。
第一种:
文章表做冗余:school 表 SCID、name、xxx 其他属性
studio 表 STID, name , xxx其他属性
article表 AID,title, content, ID(标识),name(学校/工作室名字),type(type)按照你说的,学校表和工作室表有太多不一样的列,你要在显示列表的时候,只要显示少数几列,其他的不一样的列不显示,除非是点击查看发送人的详细信息才会去查吧。。那么就在文章表上做冗余好了。查详细信息的时候,再根据type去具体的表查。以上。第二种:
学校/工作室提取共有信息。把工作室和学校的共有信息(你在列表要显示的信息)拉出来,单独做个表,然后再给工作室和学校每张做个附表挂载不一样的信息内容,表结构吐下:
id,name,type(是工作室还是学校),XXXX其他共有信息
school 表 SCID、xxx 学校的其他属性
studio 表 STID, xxx工作室的其他属性
article表 AID,title, content, ID(标识)
这样。具体用哪种,就看你的数据量大小了。是文章太多,不能允许冗余,还是学校/工作室多,联查速度很有要求。