IT wrote:
> Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.
ну например не будешь же ты связь БД много-на-много через промежуточную
сущность отображать отдельным объектом? Не будешь.
Допустим, для оптимизации каких-нибудь отчетов ты денормализуешь схему,
что, и модель так же денормализовывать? Нет. Естественно, они будут
похожи, но не всегда один в один: представь, что ты уже имеешь чужую
базу и тебе надо на ней что-то построить. Я не думаю, что твоя модель
предметной области будет идентична наследию, ей богу

> К сожалению, автор не предоставил нам достаточной информации что бы
делать столь однозначные выводы. Выносить логику в БД имеет смысл только
если это даёт явные преимущества, как-то повышение произодительности в
десятки раз. Но даже и здесь очень часто можно обойтись комбинированными
решениями.

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

Это раз. Затем, мои тезисы можно считать своеобразными предположениями,
на которые я опираюсь, и если они не соответствуют действительности —
это сразу станет очевидно и автор меня поправит.

> Здесь мы тоже имеем терминологическую путаницу. БО в классическом понимании ООП — это объект несущий в себе как данные, так и логику. Если эти две вещи разделять, то нам нужны новые термины, иначе мы можем начать называть одним термином разные вещи, ты будешь подразумевать под этим бизнес-сущность, а я сервисный объект.
Да, верно. Я имею в виду бизнес-сущность. При этом, насколько я понимаю
слова вопрошающего, у него приложение построено на domain model и
смущает только то, что бизнес-сущность должна лезть в БД.

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