我正在为用户列表开发 MySQL 数据库，并且我正在尝试确定设计它的最有效方法。
我的问题在于，有 3 种类型的用户:“一般”、“普通”和“ super ”。普通用户和普通用户仅在某些列的值上有所不同，因此存储它们的模式是相同的。但是， super 用户至少需要存储 4 列额外的信息。
此外，每个用户都需要一个唯一的user_id，以供网站其他部分引用。
因此，我可以将所有 3 个用户保留在同一个表中，但是这样我就会为一般用户行和普通用户行存储大量 NULL 值。
或者，我可以将用户分为 2 个表:一般/普通和 super 。这将消除大量的 NULL，但需要做更多的工作来跟踪 user_ids 并确保它们是唯一的，因为我必须在 PHP 中处理它，而不仅仅是这样做上面单表解决方案中的 SERIAL 列。
哪种解决方案在内存使用和性能方面更高效？
或者还有其他我没有看到的更好的解决方案吗？
谢谢!
最佳答案
如果每个用户都需要一个唯一的 ID，那么您的问题就得到了答案:您需要一个带有 UserId 列的 users 表。通常，该列将是自动递增整数主键列——这是一种很好的实现方法。
如何处理其他列？这取决于许多不同的因素，您的问题中没有很好地解释这些因素。
您可以将所有列存储在同一个表中。事实上，您可以实现 View ，这样您就只能看到一种类型的用户。但是，如果许多额外的列是固定宽度的(例如数字)，则仍然会分配空间。这是否是一个问题只是列的性质和不同用户的相对数量的问题。
您还可以将每种类型的额外列存储在其自己的表中。这将使用 UserId 与原始表建立外键关系。如果这两个键都是主键，那么join应该非常快。
还有更多奇异的可能性。如果列不需要索引，那么 MySQL 5.7 支持 JSON，因此它们可以全部放入一列中。某些数据库(特别是面向列的数据库)允许“垂直分区”，其中单个表中的不同列存储在单独的分配单元中。 MySQL(尚)不支持垂直分区。
关于php - MySQL高效: multiple tables or columns with nulls，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31118356/