@first-programmer
Допустим, есть некая таблица product, в ней описывается название, флаг активности продукта, slag, и другие вещи. Сейчас в эти другие вещи входит куча всего, чего на мой взгляд, там не должно быть. Поясню — продукт в данном случае это проект партнера, не знаю почему его так назвали в этой системе, но так есть. Так вот, в этом продукте/проекте есть данные — callback_url, secret_key, флаги какую версию api использовать для работы с этим проектом партнера. На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте. Прав ли я? Или можно все в одну таблицу пилить?
Второй вопрос. Сейчас по задаче делаю возможность формирования отчетов по этим самым продуктам для партнеров. И у каждого продукта должна быть возможность ставить флаг, нужно ли его добавлять в отчет. Вот этот флаг, опять таки, добавлять к таблице product или выносить в, допустим, новую таблицу product_report_settings? Почему сомнения? В первом описанном примере настроек много и, на мой взгляд, очевидно, что лучше их хранить в отдельной таблице. А тут просто только флаг, добавлять в отчет или нет. Вот где эта грань, когда настройки лучше вынести в отдельную таблицу? Мне кажется даже если это одно поле то лучше вынести в отдельную осмысленную таблицу. Почему?
1. Название и описание таблицы будет говорить о том, что это за данные в рамках данного продукта, для чего они нужны, для какого функционала.
2. Не будет каши в основной таблице.
3. Число настроек хоть сейчас и не предвидится увеличивать, но проект долгосрочный и там может меняться что угодно, так что и настройки дополнительные потом могут появиться.
Из минусов — лишние связи по ключам.
Что вы на эту тему думаете?
Решения вопроса 1
@romesses
- фактор неожиданности у коллеги: с какого перепугу была необходимость отделения конкретного флага?
- дополнительная таблица, для которой нужен JOIN.
- дополнительный код
- дополнительные миграции и поддержка
На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте.
Если уж отделять метаданные и настройки, так все сразу, а не ради одного флага. Тогда есть смысл в рефакторинге и приведении порядка.
1
комментарий
Ответы на вопрос 2
@DevMan
@firedragon