如何存储具有不同结构的信息？

Question

我想不出这个问题的名称，但我觉得这个问题已经解决了。我认为，我的天真让我无法在谷歌上输入正确的词，以获得我需要的结果。因此，如果以前有人问过这个问题，我会事先表示歉意。

不管怎样..。

我正在设计一个多租户web应用程序，其中数据的结构依赖于租户。在这种情况下，租户是希望使用我们的服务的企业，而用户是为其中之一工作的个人。该系统都在一个地方，因为在有一个网站，所有用户登录，取决于他们输入的电子邮件地址，他们被分配给的租户是自动决定在注册时(我不确定这是否是正确的方式进行这一点)。

每个租户都希望在我们的系统中存储有关为他们工作的人的信息。这些人不一定是用户，最重要的是，这些人的信息被用于网站的其他部分，这些部分可能更笼统。

问题是:每个租户可能想要存储关于他们的人员的不同信息。例如，假设租户A想存储姓名、电子邮件、电话和地址，而租户B想存储姓名、电子邮件、人的照片和他们最喜欢的食物(我不知道)。

我们使用SQL Server来存储数据。我的直觉是为每个租户创建一个不同的表，但是我预见到随着租户数量的增加，事情会变得更加混乱。如果我们有5个房客，那么每个桌子都能用.但如果我们有500个房客呢？我们是否需要为所有存储信息的人准备500张桌子？但情况会变得更糟。不同的信息不仅仅与每个租户的人员有关；租户可能希望我们为我们提供的其他服务存储不同的信息。

有可能以某种方式概括这种变化的数据结构吗？有谁以前处理过这种事吗？

Answer 1

您需要将所有租户之间的标准数据和不同租户之间的数据分离开来。

您可以用XML或JSON存储不同的数据。无论是大表中的单个字段，还是多个字段，都将取决于数据的性质。SQL Server具有查询JSON结构的能力，而且很可能(但我不能100%肯定)也可以对XML进行查询。

可以为XML定义模式，因此如果愿意，仍然可以验证每个租户的自定义模式的数据。我相信也有一些方法可以为JSON定义模式。

如果你不想走这条路，就有一个好的ol‘实体-属性值模型也可以处理这个问题(https://en.wikipedia.org/wiki/Entity–attribute–value_模型)

当然，您还需要确保您的系统允许用户操纵他们的自定义属性(添加新属性、更改现有属性、删除等等)--不管这些属性都被转储到JSON/XML或EAV模型中。

Answer 2

实际上，我从事的是一个项目，该项目被作为一个特性迁移到一个更大的软件中。突然间，我们有更多的公司想要访问我们的应用程序，每一家公司都给我们不同的用户信息，结果导致数据库混乱。

我们的解决方案是添加一个基本的用户表。该表保存了所有公司相同的信息:姓名、密码、电子邮件、电话和语言。最后，这只是我们的服务为了正常工作所需要的信息。此外，我们还为每个公司添加了表。我们有A公司用户和B公司用户等等。这些表包含了额外的和不同的信息和一个外键给基本用户参考必要的信息。在我们的应用程序中，我们几乎可以对基本用户的数据做任何事情，而且只有在特定于公司的服务中，才有必要访问其他表。

我的建议是:检查您的服务实际需要多少信息，并将其放入基表中。如果需要公司提供的附加信息，请将带有外键的用户表添加到基表。如果您根本不共享任何信息，那么无论如何都需要执行单个表。

Answer 3

这个问题并不新鲜，也没有“一刀切”的解决方案。如果您想保持您的系统可维护性，您需要分析每个属性的不同需求，并对如何设计它进行逐个案例的决策：

• 或者作为标准属性，对每个租户都可用(因此最好将其建模为数据库中的标准列)。
• 或者一个可供许多租户使用的属性(因此可以将其建模为数据库中的一个标准列，但只在UI中显示给那些需要它的租户)。
• 或者一个自定义属性，最好使用EAV方法建模，这是@FrustratedWithFormsDesigner或"XML或JSON“方法所建议的(通常情况下，租户希望自己自由地添加新属性，可能是在”每个记录“基础上)。
• 或者，如果该属性最适合于@pfuetz建议的“子”表(可能是特定于租户的子表，但我建议让这样的子表与应用程序的命名功能相关联，然后决定哪个租户可以访问此特性)。

请注意，标准列通常比EAV方法更容易管理:为它们实现业务逻辑将更容易，标准SQL查询将更简单，用户界面设计可以更特定于该列，数据库迁移通常更容易，它们更易于自文档化等等。因此，我建议您只在真正需要EAV的地方使用EAV，而且要谨慎使用。

当您开始为每个租户复制表并修改每个副本时，您肯定会遇到维护问题。这样做10次，您将对每个复制的属性进行10倍的维护工作。所以我强烈反对。