Я работал в системе, где у нас были такие возможности. Чтобы оставаться эффективными, мы динамически генерируем / изменяем таблицу для схемы клиента. Нам также нужно было встроить метамодель (модель модели) для динамической обработки информации в сущностях.
Вариант 1: С настраиваемыми таблицами вы получаете полную гибкость, но это также значительно увеличивает сложность, особенно обновление / миграцию существующих данных. Вот список вещей, которые вам нужно учитывать:
- Что если тип столбца изменится?
- Что если добавить столбец? Есть ли значение по умолчанию?
- Что если столбец удален? Могу ли я отказаться от существующей информации?
- Как управлять переименованием столбца?
- Как сделать вещи переносимыми между базами данных?
- Как сделать его эффективным на уровне базы данных (например, индексы)?
- Как справиться с человеческой ошибкой (например, пользователь удаляет столбец, а затем передумает)?
- Как управлять миграцией (сценарием, развертыванием и т. Д.), Когда на сайте заказчика установлена новая версия системы?
- Как это сделать при использовании ORM?
Вариант 2: Легкая альтернатива - добавить несколько «запасных» столбцов в бизнес-таблицы разных типов (например: «USER_DATE_1», «USER_DATE_2» и т. Д.) несколько раз. Это заставит вашего администратора базы данных кричать и на самом деле не считается хорошей практикой, но, по крайней мере, может облегчить несколько вещей, например, (сценарии миграции, интеграция ORM).
Вариант 3: Другой вариант - сохранить все в таблице со свойством / данными структуры. Но тогда это действительно катастрофа для производительности базы данных. Все, что не совсем тривиально, потребует много соединений. А администратор базы данных будет кричать еще больше.
Вариант 4: Это сочетание вариантов 2 и 3. Основные таблицы фиксированы, но для их расширения можно использовать таблицу со свойством / данными.
В итоге: подумайте дважды, прежде чем идти по этому пути. Это может быть сделано, но оказывает значительное влияние на разработку и обслуживание приложения.