在数据库中创建更多列或行是否更好[关闭]答案

【问题标题】：Is it better to make more columns or rows in a database [closed]在数据库中创建更多列或行是否更好[关闭]
【发布时间】：2012-05-26 17:15:52
【问题描述】：

在数据库中创建更多列或行是否更好。我正在出勤表中输入学生出勤信息。

条件 1：我应该包括 1 周列和 3 个讲座列，但这会增加每个学生的行数，因为有 16 周，每周有 3 次讲座。？？

条件 2：或者我应该添加 48 个讲座栏，分别存储每个学生的出勤情况。？？？

我看到了很多答案，但我无法得到它可以帮助我吗？提前谢谢你

【问题讨论】：

您应该阅读关系数据库理论。这是一个已经被“解决”的经典“问题”。
查看这里：- stackoverflow.com/questions/59482/…
不，建议您有一个“讲座”表，其中的列是学生姓名（或标识符）和一些日期指示，也许还有出勤指示。在那种类型的模式中，每个学生最终将与多达 48 行“讲座”表数据相关联。如果“讲座”表中有一行表示“出勤”（没有记录，没有出勤），你会得到一组问题（很难确定参加了哪些讲座），如果每一行都包括出勤率（是/否），你得到另一个（更大的表大小）。很多权衡，很多“取决于”。
您的数据库设计应该支持您的模型，而不是相反。在此处发布您的模型，我们可以帮助您设计数据库结构以支持您的模型。
这里的答案似乎是“更多表”。查找有关“数据库规范化”的信息以了解有关该主题的更多信息。

标签： sql sql-server sql-server-2008

【解决方案1】：

两者都不做。你最好有一张桌子放你的学生，一张用来上课，还有一张相交表来组合它们。

【讨论】：

感谢您的回答，所以您是说一张桌子有 48 个讲座，另一张桌子有学生和课程，并将它们组合成关系表中的一对多关系？？
是的，但您将使用多对多关系。
“更好”是主观的。为什么更好？客观上真的更好吗，如果客观上更好，客观上更好的是什么？
当然，更好是主观的。在我看来，更好的是它允许在需要时进行更改，数据以关系方式结构化，允许现在和将来需要的任何 SQL 查询。这与实施所需的工作量没有显着差异。对我来说似乎足够客观 - 我的讨论结束了。

【解决方案2】：

不要做更多的列，不要做更多的行，只是为了在你的数据库设计中遵循关系代数，为了更高的性能和 oop 你必须遵循标准规则，为了打破性能规则你应该有经验和已知的原因。您的要求应该有 1 个并且只有一个基于关系代数的表设计。 -- Sameh Fakoua

【讨论】：

【解决方案3】：

如果一个条目（每个条目是数据库表中的一个“行”）的“项目”（讲座、部件、小部件、颜色）的数量是已知且固定的，则没有理由不为这些“项目”中的每一个。处理起来会变得非常困难，因为每一行都会变得非常大——在你的例子中是 48 个讲座——但是所有的“项目”都可以通过查询你的行（在这种情况下是一个学生）来轻松定位想要。

通常，您将拥有不同的数据库布局，其中您想要的主要实体是“学生”，并且对于每个“学生”实体，都会有许多与该“学生”相关联的附加实体。这些将是“讲座”，每个“讲座”实体将与“学生”和日期相关联。在这种情况下，您将在数据库中查询“学生”，然后使用称为“连接”的关系数据库操作通过连接与“讲座”表关联的“学生”标识符来从“讲座”表中定位学生的出勤情况用“学生”的名字记录。

这种方法的优点是您可以创建其他实体——上交的家庭作业、考试或考试成绩等——然后也可以以同样的方式定位并“加入”学生。当您添加这些不同的实体时，您无需修改原始表（学生姓名加上 48 个讲座），而是创建新表（“作业”、“测试”、“考试”），然后这些表将学生姓名作为一个字段，以及日期和成绩作为其他字段。

这种方法的一个缺点是不必要的复杂性。你真的需要一张额外的桌子来保存不能改变的东西——课程的周数是由日历和课程安排确定的吗？您必须做出决定——如果“学生出勤”数据库必须应用于其他课程，以及其他时间表，您别无选择，只能增加这种复杂性。如果这只是单门课程的一次性任务，那么复杂性在以后不会给您带来任何好处。

正如 Kyser 所说，学习关系数据库理论。

【讨论】：

我不同意你的第一句话。您是否曾经不得不维护这样构建的数据库？这不过是一场噩梦。仅仅因为今天看起来“固定”的东西并不意味着它明天不会改变。应用开/关原则的精神，你应该真正应用合理数量的规范化，当你有不止一个东西时，这通常表明规范化可能是可取的。
JOIN 的危害是什么？将 48 个讲座作为列使查询非常麻烦。一个学生参加了多少？哦，如果你想添加更多信息（比如学生没有参加的原因，或者他/她上课迟到了，等等），你的数据库布局就陷入了死胡同。如果已经有代码使用它，那么在那个阶段规范化这样的表是困难且昂贵的。我对规范化不感兴趣 - 但它确实应该应用于这种情况（如果特定用途需要，您仍然可以创建非规范化视图）。
如果数据库的实际需求恰好是 JOIN 可能会或可能不会有任何危害。但是如果数据库只是一个“如果学生参加了检查列”数据库，添加额外的表，额外的列，复杂性，等等，等等，等等都是浪费。解决手头的问题，不要只是证明你知道如何制作具有非常复杂关系的巨型数据库。
如果你不想使用 JOIN，那么就不要使用关系数据库。
我的价值：规范化数据更适合通过 SQL 处理，但非规范化数据更适合人类查看。因为我不打算让人类回答我的查询，但我确实打算让 SQL Server 回答它们，所以我更喜欢规范化数据。