使用alter表实现自定义字段

正如更新一样,我们决定通过alter table将新列添加到现有的数据库表中,以实现自定义字段。经过一些研究和测试,这看起来是大多数数据库引擎的最佳解决方案。包含自定义字段元信息的单独表提供了管理、查询和使用自定义字段所需的信息。

我看到的第一个缺点是,您需要授予应用程序服务更改权限。
这意味着您的安全模型需要小心,因为应用程序不仅可以添加字段,还可以删除和重命名它们,并创建一些表(至少对于MySQL)。

其次,如何区分每个用户所需的字段?或者用户B可以访问用户A创建的字段吗?

请注意,列的基数也可能显著增加。如果每个用户添加2个字段,我们已经讨论了200个字段。

就我个人而言,我会使用这两种方法中的一种或它们的组合:

1. 使用序列化字段

我将在表中添加一个文本字段,在其中存储一个或多个序列化字典:

{ 
  user_1: {key1: val1, key2, val2,...}, 
  user_2: {key1: val1, key2, val2,...}, 
  ...
}

缺点是这些值不容易搜索。

2. 使用多类型名称/值表

字段表:

用户ID:int
字段名称:varchar(100)
类型:枚举(“int”、“real”、“string”)

值表:

字段ID:int
行ID:int主表行ID
int_值:int
浮点值:浮点
文本值:文本

当然,它需要一个连接,实现起来有点复杂,但更通用,而且如果索引正确的话,效率也相当高。

我认为向数据库表中添加新的自定义字段没有任何问题。

使用这种方法,可以使用特定/最合适的类型,即需要一个int字段?将其定义为int。而对于名称/值类型表,您将把多个数据类型存储为一个类型(可能是nvarchar),除非您用不同类型的多列完成该名称/值表,并填充适当的列,但这有点可怕。

此外,添加新列使查询更加容易/无需涉及到新名称/值表的联接。

它可能感觉不到通用性,但我觉得这比有一个“一刀切”的名称/值表要好。

从SQL Server的角度来看(2005年以后)。
另一种选择是存储创建1个XML类型的“自定义数据”字段-这将是真正通用的,不需要创建字段或需要单独的名称/值表。还有一个好处是,并非所有记录都必须具有相同的自定义数据(即,一个字段很常见,但它包含的内容不一定是相同的)。对性能的影响不是100%,但是XML数据可以被索引。