Есть система, которой пользуются несколько десятков организаций. Для подавляющего большинства эта система выглядит одинаково, но для некоторых отдельных организаций реализуются какие-то фичи, которые для других не включаются по каким-то причинам.

Вопрос в том, как правильно организовать и хранить это всё.

У нас кроме этого есть система features, где мы какой-то функционал тоже можем включать для определенных организаций, но это изначально использовалось для постепенного ввода в эксплуатацию каких-то новых фич. Включаем для тестовых организаций, проверяем, включаем для каких-то пилотных организаций, с которыми хороший контакт имеется, если всё хорошо, то включаем для всех, а механизм фичи убираем. Эта система сейчас работает через env-ы, где просто id организаций указываются.

Если вернуться к исходному вопросу, то самый простой вариант это просто в коде написать if (orgId == 1234) { ... }. Но это какая-то шляпа.

Второй простой вариант это использовать уже существующую систему features. Мне этот вариант не понравился с концептуальной точки зрения. Всё же эти фичи задумывались не для этого.

Третий вариант это в базе в таблице organizations добавить поле вида can_use_some_feature. У всех организаций кроме одной в этом поле будет false. А в коде уже проверять это поле. Я склоняюсь к этому варианту, но коллеге он не нравится, хотя сам он не может предложить ничего лучше. Типа если будет 100 фич, то таблица будет из 100 полей (я не вижу в этом проблемы, да и 100 фич в ближайшее время не предвидится, но ему не нравится).

Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим (ну или enum features, не суть). Тогда кучи полей не будет, но этот вариант уже мне кажется переусложненым на ровном месте.

Как бы тут правильно поступить?

Есть система, которой пользуются несколько десятков организаций. Для подавляющего большинства эта система выглядит одинаково, но для некоторых отдельных организаций реализуются какие-то фичи, которые для других не включаются по каким-то причинам.

Вопрос в том, как правильно организовать и хранить это всё.

У нас кроме этого есть система features, где мы какой-то функционал тоже можем включать для определенных организаций, но это изначально использовалось для постепенного ввода в эксплуатацию каких-то новых фич. Включаем для тестовых организаций, проверяем, включаем для каких-то пилотных организаций, с которыми хороший контакт имеется, если всё хорошо, то включаем для всех, а механизм фичи убираем. Эта система сейчас работает через env-ы, где просто id организаций указываются.

Если вернуться к исходному вопросу, то самый простой вариант это просто в коде написать if (orgId == 1234) { ... }. Но это какая-то шляпа.

Второй простой вариант это использовать уже существующую систему features. Мне этот вариант не понравился с концептуальной точки зрения. Всё же эти фичи задумывались не для этого. Но в принципе не вижу ничего критичного в том, чтобы расширить эту систему и ввести понятие временного флага и постоянного флага.

Третий вариант это в базе в таблице organizations добавить поле вида can_use_some_feature. У всех организаций кроме одной в этом поле будет false. А в коде уже проверять это поле. Я склоняюсь к этому варианту, но коллеге он не нравится, хотя сам он не может предложить ничего лучше. Типа если будет 100 фич, то таблица будет из 100 полей (я не вижу в этом проблемы, да и 100 фич в ближайшее время не предвидится, но ему не нравится).

Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим (ну или enum features, не суть). Тогда кучи полей не будет, но этот вариант уже мне кажется переусложненым на ровном месте.

Как бы тут правильно поступить?