我是否正确解决了我的数据库关系？

Question

如果这个问题的地方有误，我很抱歉。我自愿加入一个必须存储敏感数据的慈善团体，因为我们是一种新型格式，没有适合我们需求或预算的系统。其他人开始构建数据库，我不确定他是否正确解决了关系，所以我向他展示了另一个 ER 模型，现在我们还没有收到他的回复，所以我只能自己构建它。 由于我们必须存储敏感数据，我不愿意将我的数据库设计完整地放在这里，所以如果有办法我可以私下与某人讨论这个问题，那将是我的偏好，因为我很想找人否则要全面检查以确保一切正常...但是现在，有人可以确认我是否正确解决了这些关系，或者原始设计是否更好？

数据库描述是：有不同类型的成员-

Client, Staff, Professional (Offsite), Supplier, Family, General.  There are different types of Staff members: Managers, Volunteer, Professional (Onsite), Admin, Committee, Lecturer. A member can be one or many types eg: Client/Volunteer/Family, Supplier/Volunteer, Manager/Lecturer/Volunteer/Committee/Family.

最初的人通过为每个用户创建一个单独的表来解决这个问题，每个表存储一个名称和地址，例如：

Client - ClientName, ClientAddress
Professional - ProfessionalName, ProfessionalAddress
Employee - EmployeeName, EmployeeAddress
Family - FamilyName, FamilyAddress

我唯一的问题是，理想情况下，我希望一个人拥有一个 MemberID，其中包含他们的姓名和地址，但在原始设计中，每个人对于他们所拥有的每种类型的人都有一个不同的 ID，所有这些都存储姓名、地址、电话号码、电子邮件等

我认为创建一个 Member 表并拥有一个 Member Type 表和一个加入 Member Type List 表会是一个更好的设计。这就是我解决问题的方法：

Member Tables

我是否正确地做到了这一点，还是应该继续原来的设计？

谢谢

更新：

Staff Model

Answer 1

将所有成员相关数据存储在一个表中是有意义的。 同样对于编程，我无法想象任何支持为每种成员类型设置不同表的用例。

话虽如此，我建议您查看“用户角色”的概念，因为这看起来非常相似。

您有不同的用户（成员），他们可以有不同的角色（成员类型）。根据您的角色，您可能希望显示不同的数据/允许不同的操作/发送特定的邮件（或您可以想象的任何其他内容）。

所以通常你的方法看起来不错。我唯一想到的是，例如，现在您没有存储谁是“员工”成员。如果您只有一个名称不同的列表，则不存储结构。 根据您的用例，您可以例如在MemberType 表“isStaff”中创建另一列。或者，如果您需要更加灵活并且将来可能有更多不同的成员类型，您可以创建另一个表（例如）MemberTypeParent 并在您的 MemberType 表上设置一个外键到该表以建立连接。

这完全取决于您将来要如何处理这些数据。