1

我有一个学生实体，现在我想创建一个学生表和一个学生属性表，例如dob, age, salary. 学生属性约为120。

所以将来哪一个会更好地提高表性能和我的 MySQL 操作

选项

  1. 创建一个表（student_mst），将所有学生属性作为具有良好数据类型的列

  2. 或者，创建两个student_mst, student_attributes有关系的表（ ）并在其中添加多个学生属性记录table - student_attributes.

4

4 回答 4

1

这是两种完全不同的方法，因此这完全取决于您希望如何处理数据。仅当您选择的模型与您想要访问数据的方式不兼容时，性能才是一个问题。

如果所有学生都使用所有或大部分属性，并且有一组固定的属性，则第一种选择是自然方法。

如果学生有不同的属性集，第二个选项会很有用，并且您可能会扩展属性集。

使用第一种方法，您通常编写不同的查询来处理不同的属性。例如，获取学生列表并返回一些属性很容易。例子：

 select StudentId, Name, Age, Class, Grade
 from Students
 order by Age desc

使用第二种方法，您通常会分别获取基本学生信息和学生属性。要获得具有某些属性的学生列表会更复杂，并且它会建立您想要获得的更多属性。例子：

 select s.StudentId, Name = a1.Value, Age = a2.Value, Class = a3.Value, Grade = a4.Value
 from Students s
 inner join Attributes a1 on a1.StudentId = s.StudentId
 inner join Attributes a2 on a2.StudentId = s.StudentId
 inner join Attributes a2 on a3.StudentId = s.StudentId
 inner join Attributes a3 on a4.StudentId = s.StudentId
 order by cast(a.Value as int) desc
于 2012-10-28T10:51:43.077 回答
0

一般来说，关系数据库中昂贵的操作是恢复数据集的“行”。还能够按列过滤是一种语法糖，可以更好地调整最终数据集。因此，尝试优化排列行之间关系的方式，不要太在意列数，因为它不会影响搜索性能，而主要是“在线”上传输的数据量” 。

于 2012-10-28T11:03:20.580 回答
0

在@Guffa 的答案之上还有一些考虑

如果你确实去相关的属性表。每个学生的每个属性都会花费您一个属性 id 和一个学生 id，如果它们是整数，则说 8 个字节，因此它们的稀疏程度值得考虑。

120个属性能不能分组，可能值得一看。也许是一个属性类型 /group 和一些 1 - 1 个扩展表。

如果您只是获取一个学生及其所有属性，而不是所有具有属性的学生。

如果您计划查询的属性很少，则一个 xml 片段或序列化对象值得一看。

最后是复杂的连接查询（不想做 120 个 :)）

您可以改为旋转它们，或者您可以通过一个连接将它们作为两列返回，这将对您将它们映射到 UI 的方式产生一定的影响。

对此没有正确的答案，但如果您将架构隐藏在某些方法后面而不是在其上撒上 SQL，那么您不必在设计中一成不变。

于 2012-10-28T11:17:24.787 回答
0

一般来说，你最好让表的列组成由数据的逻辑结构驱动，并依靠索引等物理设计特性来帮助你加快速度。

一个学生的一个属性是否属于你的学生表，主要是所有学生都有这个属性的问题，还是只有部分学生有这个属性的问题。如果所有学生都有该属性，则将属性保存在学生表中通常比在检索时进行连接要快。这也是合乎逻辑的方法。

另一方面，如果您具有仅与某些学生相关的属性，那么您需要分析案例以查看您是否正在处理学生的专业子集。如果确实如此，那么您需要查找“ER Specializaton”以了解如何在概念级别对其进行建模。

如果您想了解关系设计如何实现专业化案例，请查看“类表继承”。

于 2012-10-28T17:26:16.757 回答