您将如何设计具有自定义字段的用户数据库

这个问题是关于我应该如何设计一个数据库，它可以是关系型/ nosql数据库，这取决于什么是更好的解决方案

根据要求，您需要创建一个系统，该系统将包含一个跟踪“公司”和“用户”的数据库。一个用户总是只属于一个公司

• 用户只能属于一个公司
• 一个公司可以有很多用户

“公司”表的设计非常简单。公司将具有以下属性/列：（让我们保持简单）

ID, COMPANY_NAME, CREATED_ON

第一种情况

简单明了，用户都具有相同的属性，因此可以通过关系样式，用户表轻松完成此操作：

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

第二种情况

如果不同的公司想要为其用户存储不同的配置文件属性，会发生什么情况。每个公司将具有一组定义的属性，这些属性将应用于该公司的所有用户。

例如：

• 公司A要存储：LIKE_MOVIE（布尔值），LIKE_MUSIC（布尔值）
• 公司B要存储：FAV_CUISINE（字符串）
• 公司C要存储：OWN_DOG（布尔值），DOG_COUNT（整数）

方法1

暴力方式是为用户提供一个单一的架构，并在不属于公司的情况下让其为空：

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON

这有点麻烦，因为您最终会得到很多NULL，并且用户行的列与它们不相关（即，属于公司A的所有用户的FAV_CUISINE，OWN_DOG，DOG_COUNT的值为NULL）

方法2

第二种方法是拥有“自由格式字段”：

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON

由于您不知道什么是自定义字段，因此这本身就很麻烦，数据类型将无法反映所存储的值（例如，我们将int值存储为VARCHAR）。

方法3

我已经研究了PostgreSQL JSON字段，在这种情况下，您将拥有：

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_PROFILE_JSON, CREATED_ON

在这种情况下，如何将不同的模式应用于用户？公司A的用户的架构如下所示

 {"LIKE_MOVIE":"boolean", "LIKE_MUSIC": "boolean"}

虽然拥有C公司的用户将具有不同的架构：

 {"OWN_DOG ":"boolean", "DOG_COUNT": "int"}

我应该如何解决这个问题？如何根据他们（公司）之间的关系正确设计数据库，以便为单个“对象”（用户）提供这种灵活的架构？

关系解决方案？nosql解决方案？

编辑：我也考虑过一个“ CUSTOM_PROFILE”表，该表实际上将用户属性存储在行而不是列中。

这种方法有两个问题：

1）每位用户的数据随着行而不是列的增长而增长-这意味着要获得用户的全貌，需要完成许多联接，并且需要对不同的自定义属性进行多次联接到“自定义配置文件”表

2）即使我们知道数据应该是整数或布尔值，也总是将数据值存储为VARCHAR以便泛型

请考虑将其作为替代方案。前两个示例都将要求您随着应用程序范围的扩大而对模式进行更改，此外，“ custom_column”解决方案很难扩展和维护。最终，您将得到Custom_510，然后想象一下该表将如何工作。

首先，让我们使用“公司”架构。

[Companies] ComnpanyId, COMPANY_NAME, CREATED_ON

接下来，我们还将对所有公司将使用/共享的顶级必填属性使用“用户”架构。

[Users] UserId, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

接下来，我们建立一个表，在此表中，我们将定义特定于每个公司自定义用户属性的动态属性。因此，“属性”列的示例值将为“ LikeMusic”：

[UserAttributeDefinition] UserAttributeDefinitionId, CompanyId, Attribute

接下来，我们定义一个UserAttributes表，该表将保存用户属性值

[UserAttributes] UserAttributeDefinitionId, UserId, Value

可以通过多种方式对此进行修改，以提高性能。您可以将多个表用于UserAttributes，使每个表都特定于存储在Value中的数据类型，或者仅将其保留为VarChar并用作键值存储。

您可能还希望将CompanyId从UserAttributeDefiniton表中移出，并移到交叉引用表中以供将来校对。

使用NoSQL数据库。会有公司和用户文档。用户将根据用户模板（指示该公司的字段/类型的文本）动态创建其架构的一部分。

\Company\<uniqueidentifier>
    - Name: <Name>
    - CreatedOn: <datetime>
    - UserTemplate: <Text>

\User\<uniqueidentifier>
    - COMPANY_ID: <ID>
    - FIRST_NAME: <Text>
    - LAST_NAME: <Text>
    - EMAIL: <Text>
    - CREATED_ON: <datetime>
    - * Dynamically created fields per company

这就是Firebase.com这样的外观。无论您选择哪种方式，您都必须学习如何做。

如果您经常遇到自定义字段请求，那么我实际上将其建模为数据库。创建一个表，其中包含有关每个自定义字段，CompanyCustomField（它属于谁，数据类型等）的元数据以及另一个包含CustomerId，FieldId和值的表CompanyCustomFieldValues。如果您使用的是Microsoft Sql Server之类的设备，则value列应为sql_variant数据类型。

当然，这并不容易，因为您需要一个界面，该界面可让管理员为每个客户定义自定义字段，而另一个界面则实际使用此元数据来构建UI来收集字段值。并且，如果您还有其他要求，例如将字段分组在一起或需要执行选择列表类型的字段，则需要将其与更多的元数据/其他表（例如CompanyCustomFieldPickListOptions）相匹配。

这是不平凡的，但是它的优点是不需要为每个新的自定义字段更改数据库/更改代码。自定义字段的任何其他功能也需要进行编码（例如，如果您要正则表达式验证字符串值，或者仅允许某些范围之间的日期，或者需要基于另一个自定义字段值启用一个自定义字段）。

其他答案的替代方法是拥有一个名为profile_attrib的表，或与该表完全由您的应用程序管理的类似表。

添加自定义属性后ALTER TABLE profile_attrib ADD COLUMN like_movie TINYINT(1)，您可以禁止删除它们。这将最大程度地减少您的加入，同时仍提供灵活性。

我猜这是一个折衷的选择，因为应用程序现在需要对数据库具有更改表权限，并且您必须聪明地清理列名。

您的问题有很多潜在的解决方案。一种解决方案是将其他属性存储为XML。XML可以存储为文本，或者使用支持XML类型的数据库（SQL Server）。以文本形式存储会限制您的查询能力（例如在自定义属性上进行搜索），但是如果您只需要存储和检索，那么它是一个很好的解决方案。如果需要查询，那么将XML存储为XML类型将是更好的选择（尽管这是特定于供应商的）。

只需在客户表上添加一个添加列，就可以使客户存储任意数量的属性。可以将属性存储为哈希集或字典，因为所有内容都将以字符串开头，所以将失去类型安全性，但是如果对日期，数字和布尔值强制使用标准格式字符串，则可以正常工作。

了解更多信息：

https://msdn.microsoft.com/zh-CN/library/hh403385.aspx

@WalterMitty的答案也是有效的，尽管如果遵循许多继承模型，如果有许多具有不同属性的客户，那么最终可能会有很多表。这取决于在客户之间共享多少个自定义属性。

您应该规范化数据库，以便每种不同类型的公司资料都有3个不同的表。以您的示例为例，您将获得带有列的表：

USER_ID, LIKE_MOVIE, LIKE_MUSIC

USER_ID, FAVORITE_CUISINE

USER_ID, OWN_DOG, DOG_COUNT

这种方法假定您会事先知道公司要存储的信息的形状，并且不会经常更改。如果在设计时不知道数据的形状，则最好使用该JSON字段或nosql数据库。

出于某种原因，数据库是内部平台效应最常出现的一个领域。这只是反模式弹出的另一种情况。

在这种情况下，您将尝试使用自然而正确的解决方案。公司A的用户不是公司B的用户，他们应该为自己的字段使用自己的表。

您的数据库供应商不会按表向您收费，并且不需要两倍于表的磁盘空间（实际上，拥有两个表会更有效，因为您不会为B用户存储A的属性。甚至只存储NULL。占用空间）。

当然，如果有足够的公共字段，则可以将它们分解到共享的Users表中，并在每个公司特定的用户表中都有一个外键。这种结构非常简单，因此没有数据库查询优化器会为此感到困扰。任何必要的JOIN都是微不足道的。

我的解决方案假定您将从程序中调用此查询，并且您应该能够执行后处理。您可以具有以下列：

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_VALUES

CUSTOM_VALUES将为字符串类型，存储键和值对。键将是列名，值将是列值，例如

LIKE_MOVIE;yes;LIKE_MUSIC;no;FAV_CUISINE;rice

在此CUSTOM_VALUES中，您将仅保存现有的那些信息。从程序查询时，可以拆分此字符串并使用它。

我一直在使用这种逻辑，并且运行良好，只是您必须在代码中而不是在查询中应用过滤逻辑。