会议管理系统表结构设计疑问：需2张还是3张表？

Great question! Let's break this down clearly, since the key here is figuring out what that description field actually represents—this will determine whether you need 2 or 3 tables.

First, let's clarify the core question: Is this description a one-off note tied to a specific meeting (like the creator's role or context for that particular session), or a global attribute of the user as a meeting creator (a fixed bio they use for every meeting they host)?

方案1: 2张表（推荐，适配绝大多数场景） #

If the description is directly linked to the specific meeting creation action (e.g., the creator writes a blurb about their role in this exact meeting, which might differ for future meetings they host), two tables are fully sufficient:

表1: users（系统用户表） #

Stores the fixed, core information of all system users:

• user_id (primary key)
• name (user's full name)
• email (user's contact email)
• Other standard system user fields (account status, registration date, etc.)

表2: meetings（会议表） #

Stores meeting details, plus the creator's context tied to this specific meeting:

• meeting_id (primary key)
• title (meeting subject)
• start_time / end_time (meeting timeline)
• creator_id (foreign key linking to users.user_id, to track who created the meeting)
• creator_description (the unique description the creator provided when setting up this meeting—this is the field missing from the users table)
• Other meeting-specific fields (location, attendee limit, agenda, etc.)

Why this works:

• The description is tied to the meeting, not the user. A single user might write different descriptions for different meetings, so storing it in the meetings table keeps data logically grouped.
• For the "fill in creator name and email" requirement: You can either pull this data automatically from the users table (to avoid redundancy) or add submitted_creator_name/submitted_creator_email fields to the meetings table if you need to preserve the exact values the user entered (e.g., if they used a nickname instead of their official system name).

方案2: 3张表（仅在特殊约束下使用） #

You only need three tables if the description is a fixed, global attribute of the user as a meeting creator (e.g., a bio they use for every meeting they host) and you cannot modify the existing users table (per your note that the users table doesn't include this field):

表1: users（系统用户表） #

Same as above—stores core user information.

表2: meeting_creator_profiles（会议创建者补充信息表） #

Stores user-specific data related to hosting meetings:

• profile_id (primary key)
• user_id (foreign key linking to users.user_id, with a unique constraint to ensure one profile per user)
• description (the creator's fixed meeting-host bio)

表3: meetings（会议表） #

Stores meeting details, linking to the creator's profile instead of directly to the user:

• meeting_id (primary key)
• title, start_time, etc. (standard meeting fields)
• creator_profile_id (foreign key linking to meeting_creator_profiles.profile_id)

When to use this:

• Only if you're restricted from modifying the users table (e.g., it's shared with another system) and the description is a permanent part of the user's meeting-host identity, not a per-meeting note. This adds some relational complexity, so it's not the first choice.

总结 #

In almost all cases, 2 tables are the better, simpler choice. The creator_description belongs in the meetings table because it's tied to the specific meeting, not the user's permanent identity. Reserve the 3-table approach only if you have strict constraints preventing you from modifying the users table and the description is a global creator attribute.

内容的提问来源于stack exchange，提问作者user9289573