编辑：
将所有内容都放在一张大桌子下并有一个区分不同形式的标志是一个好主意吗？
我必须建立一个包含 5 个表单（甚至更多）的网站。到目前为止，表单的字段如下：
标准化此设计的最佳方法是什么？
我正在考虑将“个人详细信息”分成 3 个不同的表：
然后用 ID 从其他人那里引用它们......
这有意义吗？看来我最终会建立很多关系......
EDIT:
Would it be a good idea to just keep it all under 1 big table and have a flag that differentiates the different forms?
I have to build a site with 5 forms, maybe more. so far the fields for the forms are the following:
What would be the best approach to normalize this design?
I was thinking about splitting "Personal Details" into 3 different tables:
and then reference them from the others with an ID...
Would that make sense? It looks like I'll end up with lots of relationships...
发布评论
评论（1）
标准化数据本质上意味着相同的数据不会在多个地方多次存储。例如，不是将客户联系信息与订单一起存储，而是将客户 ID 与订单一起存储，并且客户的联系信息与订单“相关”。当客户的电话号码更新时，只有一处需要更新电话号码（客户表），并且所有订单都将具有正确的信息而无需更新。每一条数据都存在于一个且仅一个位置。这是标准化数据。
因此，回答您的问题：不，您不会通过按照您所描述的方式分解大表来使数据库结构更加规范化。
将单个表分解为多个表的原因通常是为了创建一对多关系。例如，一个人可能有多个电子邮件地址。或者多个物理地址。分解表的另一个常见原因是使系统模块化，以便可以创建连接到现有表的表，而无需修改现有表。
将一个大表分成多个小表，它们之间具有一对一的关系，不会使数据更加规范化，只会使您的查询编写起来更加困难。*而且您不想构建您的查询除非有充分的理由，否则围绕接口（表单）进行数据库设计。通常没有。
*尽管有时有充分的理由分解大表并创建一对一的关系，但规范化不是其中之一。
Normalized data essentially means that the same data is not stored multiple times in multiple places. For example, instead of storing the customer contact info with an order, the customer ID is stored with the order and the customer's contact information is 'related' to the order. When the customer's phone number is updated, there is only one place the phone number needs to be updated (the customer table) and all the orders will have the correct information without being updated. Each piece of data exists in one, and only one, place. This is normalized data.
So, to answer your question: no, you will not make your database structure more normalized by breaking up a large table as you described.
The reason to break up a single table into multiple tables is usually to create a one to many relationship. For example, one person might have multiple e-mail addresses. Or multiple physical addresses. Another common reason for breaking up tables is to make systems modular, so that tables can be created that join to existing tables without modifying the existing tables.
Breaking one big table into multiple little tables, with a one to one relationship between them, doesn't make the data any more normalized, it just makes your queries more of a pain to write.* And you don't want to structure your database design around interfaces (forms) unless there is a good reason. There usually isn't.
*Although there are sometimes good reasons to break up big tables and create one to one relationships, normalization isn't one of them.