MySQL 5.5.57 数据库设计建议请求数据库中的“用户”表答案

【问题标题】：MySQL 5.5.57 Database Design suggestions request for 'user' table in databaseMySQL 5.5.57 数据库设计建议请求数据库中的“用户”表
【发布时间】：2018-12-08 04:41:49
【问题描述】：

我需要在教育数据库中创建一个user 表，用户可以在其中拥有以下个人资料：

1. Admin
2. School Admin
3. Tutor
4. Student
5. Parent
6. School Teacher

现在，问题是天气要为每个配置文件制作单独的表，并使用用户表中的键与配置文件表链接，或者将所有内容合二为一，并添加配置文件键来识别用户类型。每天都有新用户添加到数据库中，因此它是一个不断增长的数据库。

为获取数据而运行的查询特定于配置文件。例如，一次会为一个配置文件获取数据。但是，我们需要获取一个学生的所有老师或一个老师的所有学生的情况呢？在这种情况下，我将不得不将学生的 id 存储在导师和教师表中。优化的方法是什么？

【问题讨论】：

标签： mysql database database-design

【解决方案1】：

我会建议为配置文件制作单独的表格并使用用户表中的键来链接配置文件表（如果配置文件是预先配置的）

如果配置文件是动态的，那么您必须在您的应用程序中小心检查配置文件是否存在，如果不存在，则首先插入配置文件表，然后插入用户表。这可能会影响 INSERT 性能。

要获取一个学生的所有老师或一个老师的所有学生，您必须使用自加入

【讨论】：

配置文件是预定义的。只有一些配置文件具有配置文件特定的列，所以我可以只对包含不同列集的配置文件进行隔离吗？基本上，一些配置文件的单独表和休息在同一个用户表中
不稳定。在这种情况下，最好包含在用户表本身中。如果配置文件具有不同的属性，那么您当然应该将配置文件分开并在用户表中使用密钥。
问题在于，为每个表格分别设置表格使设计更加灵活，但也可能增加连接。制作单独表的另一个原因是用户表正在增长。每天都会增加新用户，使桌子越来越大。如果我看到 10 年之后，那么这个设计将失败。的用户将是巨大的。
还会有桥接表，因此可以从桥接表中获取一个学生的老师或导师的学生作为它的 m-n 关系。
如果我们将其分开，那么它将很灵活并节省内存，但是您说某些配置文件是特定于用户的，在这种情况下您无法避免将配置文件包含在用户表中。我总是只喜欢单独的桌子。如果您可以在应用程序中正确处理 FK，那么您可以分离配置文件表或维护桥接表。