first-programmer
@first-programmer
Backend software engineer

Когда стоит выделять данные в отдельную таблицу?

Всем привет, коллеги)

Допустим, есть некая таблица product, в ней описывается название, флаг активности продукта, slag, и другие вещи. Сейчас в эти другие вещи входит куча всего, чего на мой взгляд, там не должно быть. Поясню - продукт в данном случае это проект партнера, не знаю почему его так назвали в этой системе, но так есть. Так вот, в этом продукте/проекте есть данные - callback_url, secret_key, флаги какую версию api использовать для работы с этим проектом партнера. На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте. Прав ли я? Или можно все в одну таблицу пилить?

Второй вопрос. Сейчас по задаче делаю возможность формирования отчетов по этим самым продуктам для партнеров. И у каждого продукта должна быть возможность ставить флаг, нужно ли его добавлять в отчет. Вот этот флаг, опять таки, добавлять к таблице product или выносить в, допустим, новую таблицу product_report_settings? Почему сомнения? В первом описанном примере настроек много и, на мой взгляд, очевидно, что лучше их хранить в отдельной таблице. А тут просто только флаг, добавлять в отчет или нет. Вот где эта грань, когда настройки лучше вынести в отдельную таблицу? Мне кажется даже если это одно поле то лучше вынести в отдельную осмысленную таблицу. Почему?

1. Название и описание таблицы будет говорить о том, что это за данные в рамках данного продукта, для чего они нужны, для какого функционала.
2. Не будет каши в основной таблице.
3. Число настроек хоть сейчас и не предвидится увеличивать, но проект долгосрочный и там может меняться что угодно, так что и настройки дополнительные потом могут появиться.

Из минусов - лишние связи по ключам.

Что вы на эту тему думаете?
  • Вопрос задан
  • 116 просмотров
Решения вопроса 1
romesses
@romesses
Backend инженер
Ну вижу смысла выносить конкретное поле (флаг) в отдельную таблицу. Потому что ничего хорошего это частное отделение не даст:
  1. фактор неожиданности у коллеги: с какого перепугу была необходимость отделения конкретного флага?
  2. дополнительная таблица, для которой нужен JOIN.
  3. дополнительный код
  4. дополнительные миграции и поддержка


На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте.

Если уж отделять метаданные и настройки, так все сразу, а не ради одного флага. Тогда есть смысл в рефакторинге и приведении порядка.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
firedragon
@firedragon
Senior .NET developer
Лично я думаю что это нужно озвучить вашему партнеру. А уж он пусть думает. База ведь его.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы