Question

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

候选人：

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

Answer 1

这个评论太长了。

这既不是一个好主意，也不是一个可怕的主意。这根本不是SQL的工作方式。问题在于查询具有一组定义明确的表和列引用。这对于优化查询非常重要-通常会在运行查询之前执行此步骤。

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

有几种方法可以解决数据建模问题：

功能和关联表具有单独的表，以将它们与原始数据进行匹配。
使用实体属性值模型，该模型基本上存储键值对。
使用灵活的存储机制，例如JSON或数组。

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

您可以将表名放在列中吗？你应该吗？

1 个答案: