Я изо всех сил пытаюсь найти лучший способ хранения сущностей с пользовательскими полями. Я хотел бы иметь возможность делать запросы по этим полям, поэтому я чувствую, что нет SQL, возможно, не лучший подход. Постоянные миграции схемы кажутся болезненными, особенно потому, что разные пользователи могут захотеть разные поля в похожих объектах.
Например, допустим, у нас есть объект, представляющий деревню. Деревня имеет название (Западный город), тип (деревня), население (114). Пользователь может захотеть добавить свои собственные атрибуты в деревню, скажем, псевдоним. Это не известно заранее, и может не потребоваться для других деревень.
Лучшая техника, которую я придумал, - это таблица для сущностей, а затем отдельная таблица для «компонентов» сущностей. , состоящий из: идентификатора компонента, внешнего ключа к сущности, в которой он находится, имени компонента и его значения.
Итак, деревня из примера будет существовать как:
Table 1 - Entity
ID
1
Table 2 - String Components
ID ENTITY_ID NAME VALUE
1 1 name West Town
2 1 type village
Table 3 - Integer Components
ID ENTITY_ID NAME VALUE
1 1 population 114
Затем, если пользователь хочет добавить «псевдоним» в деревню, он может нажать кнопку sh, выбрать строковый компонент, назвать его «псевдонимом» и присвоить ему значение «Вессон»:
Table 2 - String Components
ID ENTITY_ID NAME VALUE
1 1 name West Town
2 1 type village
3 1 nickname Wesson
Затем, когда необходимо отобразить сущность, мы запрашиваем у таблиц компонентов идентификатор сущности и отображаем информацию:
name: West Town
population: 114
type: village
nickname: Wesson
Это безумие? Это как элегантный способ представления изменяемой схемы в реляционной базе данных, так и попытка обойти весь смысл реляционной базы данных. Есть ли лучший способ?