Как превратить бизнес-требования в эффективную схему БД без жертв

[Akina]

Рассмотрим на примере (пример №1), когда заказчик говорит: «У пользователя может быть только одна активная подписка». Разработчик создает таблицу subscription с полем is_active.

Что забыли учесть?

То, что активная подписка - это атрибут сущности пользователь, а не атрибут сущности подписка. То есть разработчик накосячил. Например, он должен был в таблицу пользователей добавить поле active_subscription, которое является внешней ссылкой на таблицу подписок.

Требование заказчика: «Пользователь может сменить тариф, но мы должны сохранять историю изменений для аналитики». Разработчик создает таблицы subscription и tariff и добавляет в subscriptions поле tariff_id.

Что пошло не так?

Ну так опять разработчик накосорезил... Просто проигнорировал требования заказчика. Гоните его в шею.

Дальше даже не смотрел...