Heim >Backend-Entwicklung >PHP-Tutorial >逻辑结构相同的表是否应该合成一张表?

逻辑结构相同的表是否应该合成一张表?

WBOY
WBOYOriginal
2016-06-06 20:44:371659Durchsuche

在新公司做项目的时候, 遇到的技术领导要求将逻辑结构相同的表全部合成一张表.
例如:

<code>comment #评论表
    id
    user_id
    content
    reply_id
    add_time

message #私信表
    id
    user_id
    reply_user_id
    content
    reply_id
    add_time
</code>

两张表结构相同, 然后领导让结构相同的表合并, 再加一个type进行处理, 这样可以减少相同的代码. 我觉得这样不太好, 万一之后增加功能就会比较头痛, 如果是为了减少代码的话, 两张相同结构表的model继承同一个model也就可以了, 不至于要把功能不同的表合并成一张吧, 以后如果为了节约性能, 不是还得拆表?

大家是怎样认为的呢?

回复内容:

在新公司做项目的时候, 遇到的技术领导要求将逻辑结构相同的表全部合成一张表.
例如:

<code>comment #评论表
    id
    user_id
    content
    reply_id
    add_time

message #私信表
    id
    user_id
    reply_user_id
    content
    reply_id
    add_time
</code>

两张表结构相同, 然后领导让结构相同的表合并, 再加一个type进行处理, 这样可以减少相同的代码. 我觉得这样不太好, 万一之后增加功能就会比较头痛, 如果是为了减少代码的话, 两张相同结构表的model继承同一个model也就可以了, 不至于要把功能不同的表合并成一张吧, 以后如果为了节约性能, 不是还得拆表?

大家是怎样认为的呢?

我认为所有有关数据库设计的问题,都要从「查询」这个角度来考虑。即你要预计一下你今后会如何查询这个表,再考虑如何设计结构。

回到问题,你可以考虑一下:

  • 评论是否总是和私信一起查询
  • 是否有必要在查找私信的时候查找一遍评论
  • 评论和私信的 ID 是否有必要使用同一个序列

楼主可以反过来思考,拆表。
一些访问量比较大的站,日志标题和描述是一个表,日志内容是一个表
因为别人访问日志列表的时候不一定要看到日志内容,多的日志查询就会造成一种浪费
表的合并,我认为主要是看他们在查询时,是否需要经常一起显示,如果仅仅是为了减少代码量,这个完全没有必要吧,随着以后系统用户评论内容和私信内容的增加,势必会影响到效率

数据库的表,一般情况下代表一个业务对象,如果两个业务对象属于同一类型,只是分不同类型有个别不同的字段,可以考虑公用一张表,然后用一个type字段进行区分。

楼主的例子里面,评论和私信显然不是一个业务对象,表里面的content,reply_id虽然名称相同,但代表的业务含义完全不同,所以建议分成两张表。否则后期维护的时候非常麻烦,运维的人刚开始肯定不理解,为什么同一个字段,在数据库里面根据另外另外一个type字段有不同的含义。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn