ホームページ > バックエンド開発 > PHPチュートリアル > 逻辑结构相同的表是否应该合成一张表?

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

WBOY
リリース: 2016-06-06 20:44:37
オリジナル
1658 人が閲覧しました

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

<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字段有不同的含义。

ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート