Допустим, есть некая таблица product, в ней описывается название, флаг активности продукта, slag, и другие вещи. Сейчас в эти другие вещи входит куча всего, чего на мой взгляд, там не должно быть. Поясню - продукт в данном случае это проект партнера, не знаю почему его так назвали в этой системе, но так есть. Так вот, в этом продукте/проекте есть данные - callback_url, secret_key, флаги какую версию api использовать для работы с этим проектом партнера. На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте. Прав ли я? Или можно все в одну таблицу пилить?
Второй вопрос. Сейчас по задаче делаю возможность формирования отчетов по этим самым продуктам для партнеров. И у каждого продукта должна быть возможность ставить флаг, нужно ли его добавлять в отчет. Вот этот флаг, опять таки, добавлять к таблице product или выносить в, допустим, новую таблицу product_report_settings? Почему сомнения? В первом описанном примере настроек много и, на мой взгляд, очевидно, что лучше их хранить в отдельной таблице. А тут просто только флаг, добавлять в отчет или нет. Вот где эта грань, когда настройки лучше вынести в отдельную таблицу? Мне кажется даже если это одно поле то лучше вынести в отдельную осмысленную таблицу. Почему?
1. Название и описание таблицы будет говорить о том, что это за данные в рамках данного продукта, для чего они нужны, для какого функционала.
2. Не будет каши в основной таблице.
3. Число настроек хоть сейчас и не предвидится увеличивать, но проект долгосрочный и там может меняться что угодно, так что и настройки дополнительные потом могут появиться.
это помоему уже невроз какой-то. какие дальше таблицы понадобятся?
product_report_settings, product_general_report_settings, product_report_settings_values?
лично я не вижу смысла в дроблении таблиц по вертикали
Akina, я думаю, что тут никто никакие нормальные формы не выбирал. Проекту больше 3 лет и развивался он просто спонтанно, тут разработчиков поменялось, наверно, не мало. Обычно как - кому как удобно, тот так и делает. Кто-то все в одну таблицу пишет, кто-то в разные. Я еще не встречал проектов, где целенаправленно выбирают какой формы придерживаться, прописывают в документации и применяют. Тут документации то у проекта в целом нет почти, так, общие описания. Меня интересует именно частный случай.
А тогда думайте как при анализе. Сущность? в отдельную таблицу. Словарный атрибут? в отдельную таблицу. Простой атрибут? оставить в этой. Мультиатрибут? в отдельную таблицу, плюс таблица связи.
Ну вижу смысла выносить конкретное поле (флаг) в отдельную таблицу. Потому что ничего хорошего это частное отделение не даст:
фактор неожиданности у коллеги: с какого перепугу была необходимость отделения конкретного флага?
дополнительная таблица, для которой нужен JOIN.
дополнительный код
дополнительные миграции и поддержка
На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте.
Если уж отделять метаданные и настройки, так все сразу, а не ради одного флага. Тогда есть смысл в рефакторинге и приведении порядка.
Да, это верно) Вообще я принял решение продолжить писать дополнительные поля в этой таблице. Вы правы, что тут нужен рефакторинг, но пока на него нет задачи, а значит вариант остается писать в таблицу, потому что отделять одно поле в отдельную таблицу это много накладных расходов. Если бы с нуля делал, то так бы и сделал, а так нет смысла. Вообще таблицы настроек для других таблиц это хорошая практика, позволяет например легко делать логирование настроек.
Sergey Ilichev, тут две возможности. Вы перенесли базу 1:1 или сами накосячили. В первом случае бывают веские причины оставить как есть например поле nvarchar 50 c 12 разрядными числами и 2-3 идиотами вносящими туда текст. Во втором случае конечно нормализуйте
Не понял, если честно юмора. Никто ни куда ничего не переносил. Как часто вы приходите в крупную компанию и занимаетесь новым проектом? Не часто, думаю. Вот ты приходишь, есть проект, которому больше 3 лет. Есть много сервисов, их базы данных и так далее. И вот там так все через одно место сделано. Разумеется тебе никто не даст времени рефакторить. Да, лежит все в одной таблице, да не по нормальным формам, но работает и начальству это важно, а не феншуй. Да и вопрос не в этом и не в том, кто виноват. Вопрос в том, когда пишешь новый функционал, есть ли смысл выносить каждое поле, не имеющее прямого отношения к таблице в отдельную таблицу? Я встречал разные подходы. Кто-то все лепить в одну таблицу, забивая на нормальные формы, и говорит - меньше ключей - лучше. А кто-то каждое поле выносит в отдельную таблицу следуя нормализации. Вот я хочу понять, где эта грань, между выносим из общей таблицы в настройки или или пихаем туда. У меня только один флаг, есть ли его смысл добавлять в отдельную таблицу или нет?
Владимир Коротенко, можно чуть подробнее, почему нет? Если появятся дополнительные настройки, то либо будем кашу лепить, либо нормализовать, выделяя данные в отдельные таблицы и рефакторить код, завязанный на них. Я думаю, что изначально в этой таблице тоже было одно поле настроек, а потом начали лепить второе, третье и так далее, а теперь каша из полей неизвестно для чего. Чисто ваше мнение.
Sergey Ilichev, чисто мое я выразил. Либо озвучить либо по быстрому накидать, бизнес обычно склоняется к 2 варианту. Тут в общем то зависит от того как долго вы планируете быть в конторе. Если не долго то ставьте костыли.
Средний
