EAV - Hybrid - плохой выбор дизайна базы данных

Мы должны перепроектировать устаревшую базу данных POI с MySQL на PostgreSQL. В настоящее время все сущности имеют 80-120 + атрибутов, которые представляют индивидуальные свойства.

Нас попросили рассмотреть гибкость, а также хороший подход к проектированию для новой базы данных. Однако новый дизайн должен позволять:

• n no. атрибутов / свойств для любого объекта, т. е. никакие атрибуты для любого объекта не являются фиксированными и могут изменяться на регулярной основе.

• позволяют администраторам контента добавлять новые свойства к существующим объектам на лету с использованием интерфейсов администратора вместо того, чтобы постоянно вносить изменения в схему базы данных.

Существует довольно много дискуссий о проблемах производительности EAV, но если мы не перейдем к гибридному EAV, мы закончим:

• с большим количеством пустых столбцов ( мы все равно добавляем новые столбцы, даже если 99% данных не имеют этих свойств)
• тратим больше времени на поддержку базы данных, особенно. для данного стадиона у нас может быть запрос с более чем 20 объединениями для получения всех связанных атрибутов в одной строке.

  Что вы думаете об этом проекте и что бы вы посоветовали его улучшить.

  Спасибо за чтение.