Database design: redundant column vs unused column

Question

For a project using MySQL, I have a db that looks like this:

Table #1: Column A, Column B, Column C, Column D.

Table #2: Column A, Column B, Column E, Column F.

As you can see the Columns A and B are redundant through the tables (same type, same kind of information for each table).

Someone suggested me to regroup everything under one table:

Table #1: Column A, Column B, Column C, Column D, Column E, Column F.

The problem is that some of my Items use Column C and D and some other use E and F, thus for some rows those columns will always be NULL.

What is the recommended practice here? Is there a standard design to follow? What about performance and resources (with thousands rows and ~10 tables)?

One case has redundant columns and the other case has unused columns.

Or maybe I could split the tables and create a relationship, so it gives something like:

Table #1: Column A, Column B.

Table #2: Column A (foreign key), Column C, Column D.

Table #3: Column A (foreign key), Column E, Column F.

I'm kinda lost here. This is new to me. Thank you for any input.

Answer 1

如果这些是1-1关系，我会将它们粘在一张桌子上以方便使用。没有理由不能将NULLS存储在表格中。就个人而言，我宁愿处理这个问题，而不是处理两个表之间保持密钥同步的问题。

我可以看到将它们分开的唯一主要好处是，如果要控制给定用户可以访问的信息级别，可以对不同的表放置不同的权限。例如，表A包含主人记录，表B包含联系信息。当然，您的标准用户帐户可以访问该帐户，但您可能不希望每个用户都能访问包含用户SSN的表C.

如果这些是1-n关系，那么你就是在谈论完全不同的事情，将它分成多个表格显然会更好。

Answer 2

这取决于您的查询/写入行为。如果你像你说的那样测量数千行，那么无论如何都不会产生很大的差异。

或许最好还是围绕更直观的方式规划模式。从这个角度来看，我更喜欢在两个表中看到冗余数据，以便在一个表中看到所有地方的空值。

Answer 3

这里不完全有用的答案是＆＃34;它取决于＆＃34;。您应该考虑表格所包含的列，并考虑表格的用途。

如果要从表1和表2中检索数据并在单个空间中显示数据，并且where子句将反映A列和B列的值，则将所有数据放在单个表中最有意义的。

如果你只是一次只查询一张桌子，那么就像你那样拥有一张桌子并没有太大的好处，而且试图让一件事成为两件事情。

如果＆＃34;普通＆＃34>的列数表1和表2之间将增长超过2，然后拆分表并保持＆＃34;域特定＆＃34;子表中的知识是一个很好的解决方案（查看＆＃34; Party＆＃34;来自CRM世界的一些示例的数据模型，在这种情况下）。

大多数数据库都会压缩空列，因此现在没有任何物理原因可以选择其中一列。