Комментарии 1
Рассмотрим на примере (пример №1), когда заказчик говорит: «У пользователя может быть только одна активная подписка». Разработчик создает таблицу subscription с полем is_active.
Что забыли учесть?
То, что активная подписка - это атрибут сущности пользователь, а не атрибут сущности подписка. То есть разработчик накосячил. Например, он должен был в таблицу пользователей добавить поле active_subscription, которое является внешней ссылкой на таблицу подписок.
Требование заказчика: «Пользователь может сменить тариф, но мы должны сохранять историю изменений для аналитики». Разработчик создает таблицы subscription и tariff и добавляет в subscriptions поле tariff_id.
Что пошло не так?
Ну так опять разработчик накосорезил... Просто проигнорировал требования заказчика. Гоните его в шею.
Дальше даже не смотрел...
Как превратить бизнес-требования в эффективную схему БД без жертв