Question

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

因此，未来对于表性能和我的MySQL操作会更好

选项

创建一个表（student_mst），其中所有学生属性都是具有良好数据类型的列
或者，创建两个包含关系的表（student_mst, student_attributes），并在table - student_attributes.

Answer 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

Answer 2

通常，关系数据库中昂贵的操作是恢复数据集的“线”。能够按列过滤也可以作为语法糖来更好地调整最终数据集。因此，尝试优化排列线之间关系的方式，并且不要过多关注列的数量，因为它不会对搜索性能产生影响，但主要取决于将在线上传输的数据量“。

Answer 3

@Guffa

的答案之外还有一些考虑因素

如果你去了相关的属性表。每个学生的每个属性都会花费你一个属性id和一个学生ID，如果它们是整数，就说8个字节，所以它们是多么稀疏值得考虑。

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

如果您只是获得学生及其所有属性而不是所有具有属性的学生。

如果您计划查询的属性非常少，那么其余的xml片段或序列化对象值得一看。

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

你可以改为转动它们，或者你可以用一个连接作为两列来取回它们，这会对你如何映射它们以说明UI有明确的影响。

对此没有正确的答案，但如果您隐藏某些方法背后的架构而不是将SQL全部展开，那么您的设计中并不是必须设置的。

Answer 4

一般情况下，最好让表的列组成由数据的逻辑结构驱动，并依靠索引等物理设计功能来帮助您加快速度。

学生的属性是否属于学生表主要是所有学生是否具有此属性的问题，或者只是某些学生的问题。如果所有学生都具有该属性，则将该属性保留在student表中通常比在检索时进行连接更快。这也是合乎逻辑的方法。

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

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

数据库速度取决于列或行（记录）？

4 个答案: