我在重新创建Users和Items之间具有一对多（1：M）关系的数据库时遇到了一些麻烦。
这很简单，是的；但是，每个Item 都属于某个类别（例如，汽车、船或飞机），并且每个类别都有特定数量的属性，例如：
Car 结构体：
+----+--------------+--------------+
| PK | Attribute #1 | Attribute #2 |
+----+--------------+--------------+
Boat 结构体：
+----+--------------+--------------+--------------+
| PK | Attribute #1 | Attribute #2 | Attribute #3 |
+----+--------------+--------------+--------------+
Plane 结构体：
+----+--------------+--------------+--------------+--------------+
| PK | Attribute #1 | Attribute #2 | Attribute #3 | Attribute #4 |
+----+--------------+--------------+--------------+--------------+
由于属性（列）数量的这种多样性，我最初认为为每个Category创建一个单独的表是个好主意，因此我会避免多个NULL，从而更好地利用索引。
虽然一开始看起来不错，但我找不到通过数据库创建Items和Categories之间关系的方法，因为至少以我作为数据库管理员的经验来看，在创建外键时，我明确地通知了数据库表名和列。
最后，我想要一个可靠的结构来存储所有数据，同时拥有所有方法来列出用户可能通过一个查询拥有的所有 …
我必须为涉及音乐艺术家描述的业务环境设计实体关系图 (ERD) ，我将在下面详细说明。
一个艺术家有一个名称，且必须要么一组 或一个独奏演员（但不能同时）。
一个小组由一名或多名独舞者组成，并有若干成员（应根据组成该组的独奏者人数计算）。
一个独奏演员可能是一个会员众多的群体或无的集团，并可以播放一个或多个仪器。
如何构建一个 ERD 来表示这种场景？我对它的“或”部分感到困惑。
我正在设计一个数据库来存储不同类型的用户。主要（但不完全）他们将是演员、导演和作家。目前只有四种相关的用户类型。这个数字有增加的可能性，但概率很低——在这种情况下，这个数字会非常小。
该计划是有一个users几乎完全负责登录站点的表（name,email和password列加上一两个其他的，例如它们是否已被批准，和 update_at），以及每个用户类型的附加表，每个用户类型有自己独特的一组列。例如，只有演员才有种族栏，只有导演才有简历栏，只有作家需要提供他们的位置。但是，由于我之前没有管理过如此复杂的数据库，我想知道如何组织几个方面：
首先，用户可以是上述类型中的任意一种或任意组合。所以我知道我需要像（例如）一个director_user带有director_id和user_id列的表格。那么这是否足以能够按角色类型等过滤所有用户？
其次，大多数用户会选择 Twitter 个人资料和电话号码。并且所有演员都必须至少包含一个 URL，用于其他任何在线演员的个人资料；目前他们可以包括三个，但这个数字可能会增加。我是否正确假设每个可能的配置文件/联系方法的单独表格是组织数据的最佳方式？