简体   繁体   中英

What is the best way to structure my database tables?

I'm having trouble designing my database schema.
I am having doubts on whether to separate or group tables.

I have a blog and a News section in my application and database. Both receive Comments and Likes.

TABLE.BLOG | TABLE.COMMENTS.BLOG | TABLE.LIKE.BLOG
TABLE.NEWS | TABLE.COMMENTS.NEWS | TABLE.LIKE.NEWS

I share everything?

TABLE.BLOG | TABLE.NEWS
TABLE.COMMENTS | TABLE.LIKE

or should I keep comments grouped?

In case I should have some kind of reference type blog | news?

I am very confused about the best way to structure the database.
I really appreciate if someone can help me.

Although the exact layout depends mostly on the way that you are going to access and use your data, you are probably going to be better off with comments and likes sitting in the same table. Your second approach is close, although I would probably introduce a third table, called CONTENT , with an ID of anything that could be liked or commented.

Each row in the NEWS and the BLOG table would have a corresponding row in the CONTENT table. A CONTENT row could correspond to either a NEWS or a BLOG , but not both. CONTENT table has attributes common to blogs and news (date, title, author, and so on).

The LIKE and COMMENT tables would then be connected to the CONTENT table, so you would not need to duplicate these two tables for NEWS and for BLOG .

Here is an illustration:

插图

Best is subjective, though I'd have two tables:

Content  (news and blog content, store like count)
Comment  (news and blog comments)

and then add a type field on both that distinguishes between blog and news. That way you can reuse a lot of the db code.

IOW, minimize the number of tables if you can.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM