Вы можете поместить имя таблицы в столбец? а ты должен?

Я хотел бы создать хорошо масштабируемую систему для хранения «кандидатов», проблема в том, что каждый кандидат имеет разные «функции», а иногда они имеют разные типы данных. Одна идея, которую я хотел бы попробовать, включает что-то вроде этого:

кандидаты:

| 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 и поместите результаты в новые таблицы. Но в идеале я бы использовал кучу материализованных представлений и периодически обновлял их, потому что мне кажется, что это будет лучше масштабироваться с большим количеством данных.