sil*_*min 10 mysql database-design relational-database
我有4种类型的用户,每个都有具体的数据,但他们也分享COMMUN数据,如username,password..
我的第一个想法是创建一个users带有user_type列的主表.然后,当查询用户数据时,我可以先选择它们user_type然后根据output运行不同的查询来获取"用户类型"特定数据.我不喜欢这个,因为我希望我能用一个查询获取所有用户相关数据,理想情况下使用外键.
第二个想法是user_type在users表中没有列,而是使用来自特定用户类型表的外键将指向主users表的行.我喜欢那样好一点虽然我想我将不得不运行N个查询,其中N是每次我需要获取用户数据时的用户类型数.
还有其他选择吗？在这种情况下,什么是好的做法？
非常感谢
Wal*_*tty 16
您的案例看起来像是类/子类的实例.
设计SQL表以处理子类有两种经典方法.每个都有优点和缺点.
一种方法称为"单表继承".在此设计中,只有一个表适用于所有类型的用户.如果给定列不属于给定行,则交集将保留为NULL.可以添加列以指示用户类型.
另一种方法称为"类表继承".这很像Nanego给出的答案,只有一些小的改动.用户可以使用一个表,包含所有常用数据和一个id字段.每个子类都有一个表,其中包含与该子类相关的数据.id字段通常设置为users表中匹配行中的id字段的副本.这样,子类键可以执行双重任务,既充当主键,又充当引用用户表的外键.最后一种技术称为"共享主键".它需要在插入时进行一些编程,但这非常值得.它强制执行关系的一对一性质,并加速必要的连接.
您可以在SO中查找所有这三个设计作为标签,也可以在网络上查找文章.
单表继承 class-table-inheritance shared-primary-key
尽管它更有效地利用了磁盘空间，但拆分为单独的表的问题在于您实际上需要条件连接 - 基于 user_type 连接到用户类型特定的表。用 SQL 编码很痛苦，现在谁关心磁盘空间？
更好的选择是让一个用户表有足够多的列来存储有关任何用户类型的信息，知道某些列不会用于某些用户类型。拥有未使用列的“低效率”将在执行速度和查询简单性方面得到更多补偿。
它也很容易扩展，以防您获得另一种用户类型 - 添加列比添加表要容易得多，并且随着您添加更多用户类型，对新列的需求会减少（只是没有那么多不同您需要存储的有关用户的信息）