一个大表还是多个表？

Question

I am trying to build a website that has a similar design to the way Facebook groups work. Users will be able to join groups and then post within those groups. However, I am having trouble creating the database schema in regard to groups and posts. This is my table schema thus far:

Table 1: Users
Table 2: Groups
Table 3: Posts

The posts table will create a row every-time a user posts within a group. That row within the post table will have the unique ID of the group that post is for as well as the unique ID of the user who created the post. My worry is that the post table will become massive, especially massive in comparison to the Groups and Users tables.

considering that there will be many posts (hundreds to thousands) per group, should I create a new table for every group?

Any and all input on this matter would be greatly appreciated.

Answer 1

In a word, NO. You should NOT create multiple tables. One groups table is appropriate. Index it appropriately it should be fine. Hundreds or thousands of posts is practically nothing to a database, which is designed to be able to manage millions of rows with proper indexing. A column of your table should identify the group ownership, but you should not split it into different tables.

In the very worst case, you could partition your table when it became unmanageably large to fit in your disk space. However, the likelihood of it growing that large is incredibly small.

Answer 2

除非您有成千上万的帖子，或者帖子可能很大，或者您的硬件非常有限，否则只要使用组ID索引，就可以使用单个MySQL表。

Answer 3

除非我们谈到百万条以上的行，否则只要您正确索引表（通过两个ID进行索引）就可以了。

Answer 4

Put in simplistic view, if there is a dependency of any kind between data items then a new table should be created. You can look it up more precisely here: http://en.wiktionary.org/wiki/first_normal_form

It does not state though that a new table should be created every time the table becomes too large. That would be something for a database administrator. In your example, the most recent posts will be read more often than those written 5 months ago. For the sake of proper indexing and to avoid duplicates in data rows, you could use a structure like this:

Note) This diagrams says that; i) one user will post to one or more groups, ii) one group will have one or more users, iii) one post will be viewed by one or more users in a group. All 3 relations are one-to-many and the cardinality between users and group is many-to-many.

Moreover, you could "group/structure" your posts, - the table that is likely to grow over time - into years, months or even weeks. So then you would be able to say for which time period, whereby you could also make this time factor a date field in your posts table instead of a separate table.