你能把一个表名放在一个列中吗？你呢？

Question

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

候选人：

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

candidateFeatures：

| 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中将结果放入新表中。但理想情况下，我会使用一堆物化视图并定期更新，因为感觉它会随着更多数据更好地扩展。

Answer 1

这个评论太长了。

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

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

有办法解决数据建模：

• 为功能和关联表提供单独的表，以使它们与原始数据匹配。
• 使用实体 - 属性 - 值模型，它基本上存储了键值对。
• 使用灵活的存储机制，例如JSON或数组。

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