Доброго дня!
Имеется таблица в несколько миллионов записей, в которой хранятся записи об одной сущности разных типов (пусть будут условно лампочки).
Таких типов порядка десятка штук (условно лампы накаливания, светодиодные и т.п.)
Заказчик хочет видеть в UI определенный тип сущностей особым образом, отдельно ото всех остальных типов.
Разработчики в моей команде предложили выделить данный тип сущностей в отдельную таблицу (например вынести в эту таблицу все светодиодные лампочки),
мотивируя это тем, что не придется переписывать старые хранимки (порядка 30 штук) и так как им будет проще понимать код.
Я против подобного подхода, т.к. критериев выделения новых сущностей из существующих может быть много (завтра заказчик захочет видеть в UI светодиодные лампы, но определенной мощности или формы),
и под каждый критерий выделять новую сущность (таблицу) в базе, писать к ней хранимки и новый код — путь к усложнению кода за счет роста количества сущностей и связей между ними.
Как мне кажется лучше переписать имеющиеся хранимки и сделать их более гибкими.
Хотелось бы узнать мнение общественности.
Есть ли критерии, по которым можно было бы однозначно принять решение о выделение новой сущности из имеющегося набора сущностей, отличающихся только типами?
С точки зрения производительности могу сразу сказать, что база не нагружена, т.е. таких проблем не стоит.
Весь вопрос в архитектурном подходе.

Здравствуйте, BillyBoy, Вы писали:

BB>Весь вопрос в архитектурном подходе.

Вы правы. Не выделять, т.к. это ни к чему хорошему не приведет.

Здравствуйте, BillyBoy, Вы писали:

BB>Заказчик хочет видеть в UI определенный тип сущностей особым образом, отдельно ото всех остальных типов.

Значит, с точки зрения бизнеса одни сущности отличаются от других. Надо понять почему, заглянуть чуть дальше.
Затем эту информацию (об отличиях) воплотить в БД (например, в виде дополнительного поля).

BB>Как мне кажется лучше переписать имеющиеся хранимки и сделать их более гибкими.

Да, лучше переписать хранимки.

А таблицу может и придется добавить. Но не для хранения конкретного одного вида (типа) лампочек, а для хранения дополнительных свойств, относящихся к различным типам лампочек.

Здравствуйте, BillyBoy, Вы писали:

BB>Есть ли критерии, по которым можно было бы однозначно принять решение о выделение новой сущности из имеющегося набора сущностей, отличающихся только типами?

Можно выделить отдельную сущность в бизнес-слое или в UI слое, если разработчикам так удобнее.
Выделять ли таблицу в слое хранения, на мой взгляд, нужно определять соображениями целостности данных и производительности.

P.S. Если с изменением хранимок проблемы, может пришло время их порефакторить?

Здравствуйте, BillyBoy, Вы писали:

BB>Есть ли критерии, по которым можно было бы однозначно принять решение о выделение новой сущности из имеющегося набора сущностей, отличающихся только типами?
Критерии есть, но они нечеткие (что есть сущность вопрос философский). Если у некоей совокупности элементов одной сущности стали выделяться очевидные классификационные признаки и поведение, не удовлетворяющие требованиям к существующей, то можно выделить в отдельную сущность. Если эти признаки и поведение проявляются только в отчетах, то можно не выделять. В этом случае надо смотреть на соотношение выгода/затраты от такого выделения.

Например, была сущность Контрагенты. Но в процессе развития бизнес-процессов, появилась необходимость выделения сущности Заводы, поскольку они обладали уникальным признаком — производство. В этом случае выделение оправдано, поскольку у заводов другой учет, другие KPI и еще масса признаков, отличных от непроизводящих контрагентов.

BB>Имеется таблица в несколько миллионов записей, в которой хранятся записи об одной сущности разных типов (пусть будут условно лампочки).
BB>Таких типов порядка десятка штук (условно лампы накаливания, светодиодные и т.п.)
BB>Заказчик хочет видеть в UI определенный тип сущностей особым образом, отдельно ото всех остальных типов.
BB>Разработчики в моей команде предложили выделить данный тип сущностей в отдельную таблицу (например вынести в эту таблицу все светодиодные лампочки),
BB>мотивируя это тем, что не придется переписывать старые хранимки (порядка 30 штук) и так как им будет проще понимать код.


К новой таблице все равно ведь придется как-то обращаться? То есть те или иные манипуляции с кодом все равно будут. А раз так, то (исходя из того, что приложение ваше собственное и вы можете делать что хотите) я бы добавил к существующей таблице поле "ТипОтображенияВИнтерфейсеПользователя" и, в зависимости от его значения...

Ну или вьюх понаделал бы над таблицей.


BB>Я против подобного подхода, т.к. критериев выделения новых сущностей из существующих может быть много (завтра заказчик захочет видеть в UI светодиодные лампы, но определенной мощности или формы),
BB>и под каждый критерий выделять новую сущность (таблицу) в базе, писать к ней хранимки и новый код — путь к усложнению кода за счет роста количества сущностей и связей между ними.
BB>Как мне кажется лучше переписать имеющиеся хранимки и сделать их более гибкими.
BB>Хотелось бы узнать мнение общественности.
BB>Есть ли критерии, по которым можно было бы однозначно принять решение о выделение новой сущности из имеющегося набора сущностей, отличающихся только типами?


Если набор атрибутов не отличается, то выделять, с точки зрения архитектуры приложений баз данных, не стоит.

Здравствуйте, TMU_1, Вы писали:


TMU>я бы добавил к существующей таблице поле "ТипОтображенияВИнтерфейсеПользователя"

Вот этого я бы делать не стал. Мухи (данные) отдельно, котлеты (UI) отдельно.
TMU>Если набор атрибутов не отличается, то выделять, с точки зрения архитектуры приложений баз данных, не стоит.