你能把表名放在一列吗？你应该吗？答案

【问题标题】：can you put a tablename in a column? and should you?你能把表名放在一列吗？你应该吗？
【发布时间】：2019-03-08 11:51:54
【问题描述】：

我想创建一个高度可扩展的系统来存储“候选人”问题是每个候选人都有不同的“特征”，有时这些具有不同的数据类型。我想尝试的一个想法是这样的：

候选人：

| id |    cType   |
   1    'fabric'
   2     'belt'

候选特征：

| candidateId | featureTable | featureId
       1          'city'         1
       1         'colour'        1
       1         'colour'        2
       2          'city'         2
       2          'size'         1

城市：

|id | lat | lng |   name  |
  1    x     x    'London' 
  1    x     x     'Paris'

颜色：

|id |  name  |
 1    'Red'
 2   'Green'

尺寸：

|id |  value  |
 1     10
 2     12

在这里，您可以看到伦敦有一种面料候选者具有红色和绿色特征，而巴黎有一种腰带候选者尺寸为 10。我们这样做是因为我们以通用的方式获得反馈，并且我正在尝试编写一个可扩展的机器学习解决方案，该解决方案将允许无缝添加新类型的候选者，以及新的候选者特征类型——因为它们被发现并添加到分贝。假设候选者能够拥有一种以上的每种特征类型。最终，我需要能够提取数据（可能通过物化视图），这样如果我想要所有“面料”候选者，我最终会得到类似的结果：

'id' |  colourIds  |  cityIds  |
  1     [1, 2]         [1]
  4      [3]         [4, 5]

但是，如果有一天我发现一种没有颜色但有图案的织物，我可以轻松获得一个新的图案表，只需将特征添加到我的“candidateFeatures”表中：

'id' |  colourIds  |  cityIds  | patternIds
  1     [1, 2]         [1]        null
  4      [3]         [4, 5]       null
  14      null         [6]        [1]

这种格式适合前端，“candidateFeatures”的格式对后端非常有用。我们可以使用它在不修改现有表的情况下轻松扩展，并进行可扩展的数据分析。特别是在寻找用户对候选者的反应与存在分类特征或连续特征值之间的相关性时。

对我来说，这似乎是一个非常聪明的想法，但在 sql 中没有得到适当的支持……这让我觉得这可能是一个伪装的非常愚蠢的想法。我认为使用 EXEC 可以做到这一点，但这确实有一些风险。有谁知道实现相同结果的更聪明的方法？或者实际上如何实现这一目标？由于执行时间不是一个大问题，我总是可以通过第三方程序运行它，例如在 python 中并将结果放入新表中。但理想情况下，我会使用一堆物化视图并定期更新它们，因为感觉它会随着更多数据更好地扩展。

【问题讨论】：

这是一个众所周知的“动态属性”问题。您的第一个模型称为（反）模式实体属性值。现在我只会创建表candidate，其中所有常见属性作为适当的列，以及一个存储键/值对的JSONB 列以存储候选特定属性

标签： sql postgresql database-design

【解决方案1】：

评论太长了。

这既不是一个好主意，也不是一个糟糕的主意。这根本不是 SQL 的工作方式。问题是查询有一组明确定义的表和列引用。这对于优化查询非常重要——这一步通常发生在查询运行之前。

查询不仅仅是在处理数据时允许动态替换的字符串。

有一些方法可以解决数据建模问题：

为特征和关联表提供单独的表，以将它们与原始数据相匹配。
使用实体-属性-值模型，该模型主要存储键值对。
使用灵活的存储机制，例如 JSON 或数组。

此外，Postgres 支持称为继承的东西，它可能对表示这种类型的数据很有用。

【讨论】：