2

为系统中的两个不同的配置文件（在我的例子中是教师和学生）通用一个配置文件表是否有意义？我正在这样做，只是想对我的设计方法进行一般的健全性检查。回应表示赞赏。背景如下：

我们正在构建一个既有教师又有学生的网络系统。两者都在系统中有帐户。两者在系统中都有配置文件。

我的问题是关于那些 Profile 表的表设计。

教师资料在与其关联的元数据方面是相当静态的。每位教师都有一组字段，用于公开有关该人的信息（学校、学位等）。然而，学生却是另一回事。我们正在使用 Windows 服务从源源不断的 Excel 电子表格中提取有关学生的各种数据。

数据被移动到我们的数据库中，然后这些字段与学生的个人资料相关联。因此，每个学生的个人资料中可能有非常不同的领域。

我最初是从三个表的概念开始的：

账户

AccountID

教师简介

TeacherProfileID
AccountID
SecondarySchool
University
YearsTeaching
Etc...

学生档案

StudentProfileID
AccountID
Header
Value

该StudentProfiles表将保存 Excel 电子表格中列标题的名称和相关值。

从那以后，我对设计进行了一些改进，以便根据附加的 ERD 图像更通用地处理配置文件。教师和学生的“标题”存储在一个名为的表中ProfileAttributeTypes，并且响应（来自 Excel 文档或通过 Web 表单上的输入字段）放在一个ProfileAttributes表中。这样，学生和教师个人资料都可以与个人资料字段的动态流相关联。“权限”表告诉我们我们是在与学生打交道还是与教师打交道。

由于该系统可能会快速增长，因此我想确保基础牢固。您能否提供有关此设计的反馈，并让我知道它是否看起来不错，或者您是否可以看到它可能产生的问题，如果是这样，什么可能是更好的方法？

提前致谢。

简介

4

3 回答 3

1

我不认为你的设计很好。该模型混合了用户和实体的概念。

这是一个更合适的设计的开始。

t_User

t_User_Settings（配置文件）

t_Permissions

t_Actions

t_学生

t_Teacher

t_Student_Attributes

t_Teacher_attributes

用户相关项目/属性属于 t_User 或 t_User_Settings 域相关项目/属性属于 t_Teacher/t_Teacher_Attributes 或 t_Student/t_Student_Attributes

您可以通过外键将域概念（教师/学生）与用户概念相关联。或者您可以创建一个 t_Teacher_User + t_Student_User 表。

请注意，您如何仅通过读取表名就可以准确地知道去哪里了。

于 2012-04-15T00:58:49.730 回答
1

财产袋方法

您提出的数据模型依赖于“property-bag”（配置文件的键值项的集合）。该模型的优点在于您可以扩展您的属性而无需更改数据模型。

缺点是您经常需要“透视”数据，并且您的表（和索引）会很快膨胀。（我的经验：50K 记录的每个键 200 个属性 = 1000 万个属性，而无需跟踪属性的更改。）

如果您主要需要查询一个特定属性的键，则可以推荐使用此模型。思考诸如“有多少人拥有数学学位？”之类的问题。其中数学学位是属性键。

XML字段方法

通过这种策略，我们向表中添加了一个“xml”字段，该字段以 xmlProfiles的形式获取属性列表。此模型还允许您扩展属性的数量，而无需更改数据模型。

Sql Server 对此类字段有很好的支持（通过 xpath 查询、xml 索引等），其好处当然是您保留了一个简单的数据模型，允许您在 xml 字段中存储您喜欢的任何内容。

当字段内容被整体替换时，建议使用此模型，您可以通过xpath查询更改xml字段中的数据，但速度很慢。

稀疏列

SQL Server 2008 中引入了稀疏列系统，允许您在未密集填充的表中创建许多不同的字段。好处是它允许您创建比 1024 限制更多的列，并且未填充的字段在未填充时不会占用空间。

缺点是您需要预先了解所有可能的字段，否则每次遇到新字段时您都会查看数据模型的更改。如果您的表中大部分是空列，则此模型非常有用。

采取哪种方法？

这是困难的部分，这完全取决于您想对数据做什么。根据我的经验，属性包方法适用于小型数据集，并且如果您不需要跟踪属性的更改。（我见过1个月后表中有超过10亿条记录的情况）

当您经常需要查询字段的特定内容时，Xml 字段可能会非常痛苦，但它非常适合存储只会“按键”请求的信息

当为少于 30%-40% 的记录填充列时，稀疏列效果很好。

附加说明：在您的数据模型中存储诸如“教学年数”之类的内容被认为是一种不好的做法，因为您必须始终更新该值。最好存储“教学开始年份”并计算增量。

于 2012-04-09T20:23:28.080 回答
0

根据我的经验，健全性检查数据模型的最佳方法是计算出您可能需要的查询/DML。

正如 Filip de Vos 所写，您的“property bag”方法并不容易适用于典型的关系查询——“select count(*) from students where course = 'maths' and score > 12”将是一个巨大的痛苦。

另一方面，您的初始设计确实解决了有关存储架构变化或在设计时未知的数据的问题。

在实践中，您通常最终在典型的关系模型中对“固定”的东西进行建模，并使用属性包或 XML 文档对变量位进行建模。如果您在设计时能够清楚架构，“稀疏列”也可能会有所帮助。

于 2012-04-17T10:35:51.470 回答