адреси, контактні особи, переписка, контракти, замовлення і т.д. і.т.п.

Все, что вы сказали, лежит в других таблицах и отделено от клиента километрами логики.

У фізособи частини цих даних немає. Зате є інші, яких немає в юрособи — ПІБ, паспорт, ІПН, громадянство і т.д. і т.п.

Это все отдельные таблицы с более сложными связями, чем вы тут привели. Например, документы — это связь * - * через джойн таблицу, которая сама по себе представляет отдельную сущность и в свою очередь имеет логику работы, в т.ч. на уровне кода, а прямой связи между клиентами и документами нет. Так что не надо рассказывать про отдельные таблицы.

Тем не менее, в клиенте продолжает хранится огромное кол-во информации, которая общая для всех типов, и лишь в некоторых данных отличается. И типов клиента гораздо больше, чем 2. И вы, похоже, не понимаете, что клиент с точки зрения бизнеса, это некая единая абстракция, и он может быть хоть газообразной формой жизни с планеты Нибиру — это все равно клиент, и он должен вкладываться в логические процессы работы с обобщенной моделью клиента. И если у вас чего-то не хватает — вы выделяете общие характеристики из нехватающих в существующей модели, и добавляете ее в модель абстракции клиента. Плодить таблицы для каждого подвида общей сущности — это подход выпусника гоайти.

інформація про клієнта-фізособу повинна лежати в головній таблиці Client ?

Даже в вашем вопросе содержится прямое указание на то, что у вас плохо с моделями. Перефразирую ваш же вопрос — «почему клиент хранится в таблице клиента», подумайте над этим.

Як це випливає з бізнес-логіки ?

Непосредственно.

Косплею Владимира:
Мне не нужен стык! Почему я должен находить на стыках? Я никому ничего не должен! Как стыки помогут мне заработать денег?
:)

однією таблицею для фізосіб і юросіб прокоментувати

Т.е., вы предлагаете разнести на две таблицы таблицу, в которой 40 других полей будут идентичными, ради 3 полей с разной логикой, и которые на самом деле содержат информацию об одной и той же сущности, с разным полем type? Прям каминг-аут.

я навіть не знаю, як цю дурню з полями на ПІБ для юрособи

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

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

оскільки це bad design

Bad design — это то, что вы не понимаете элементарных вещей — что есть бизнес-логика сложнее чем сущность Student(age, name) на два поля и что необходимо поддерживать консистентность соблюдая очень много условий.

переносити це гавно в новостворену систему, яка це легасі обслуговує

Гавно — это то, что получится у вас с таким подходом, когда вам нужно будет смоделировать сущность с 50 полями, 20 из которых — вложенные структуры, некоторые на 8 уровней глубины вложенности и несколькими тысячами строк логики, валидации, дефолтных значений, собственными исключениями, и перечнем бизнес-рулов на 15 страниц документации. Да, это ентерпрайз-реалии. Да, я понимаю что вы к ним не готовы.

Не надо путать неспособность в сложные вещи с стремлением к хорошему дизайну.

Але зразу таке будувати — так ми дійдемо до того, що будемо окремими полями тримати shortName, fullName i PIB — а раптом буде потрібно.

Если надо будет — будете. И держать, и следить за соблюдением консистентности.

Потому что есть клиентские данные, их могут быть десятки полей, сотни. И это не просто поля, они логически зависят друг от друга, иногда целыми графами. Завтра ваш клиент может стать юр.лицом, и вы введете колонку типа. И для тех, у кого тип -
юрлицо, вы должны будете поддерживать в middleName, lastName — null, потому что у юрлица не может быть отчества и фамилии, и это в том числе отразится на вашей бизнес-логике в коде, как

public void setMiddleName(String mN) {
if (this.type.equals(COMPANY)) {
throw «Company cannot have middle name»;
}
....
}

Потому что клиент — это сложная сущность с большим количеством гипотетических состояний.

в сеттерах прийдеться робити набагато більше.

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

тобто в базі у вас теж чотири поля, одне з яких є об’єднанням трьох інших ?

Да. Я думал, что это было вроде как очевидно с самого начала.

Ок, фіг з нею, нормалізацією

А что с ней?

отримуємо проблеми з забезпеченням цілісності даних на рівні СУБД

Нет.

повинні бути дуже серйозні причини, щоб тримати в об’єкті поля, що по-суті є похідними

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

ентерпрайзу і бізнес-сутностей — сумніваюсь.

Сомнение вещь конечно благородная, но сомневаетесь вы зря.

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

Чого раптом fullName став «полем в сущности»

Потому что кто-то не читает сначала:

Представим Client, у которого есть поля name, firstName, middleName, lastName. При этом есть логика, согласно которой name = fN + mN + lN с пробелами.

name — персистентное поле, как и другие, кототорое всегда должно содержать в себе конактенацию трех других полей и так и храниться и сохраняться. Это сильно упрощенный кейс для примера, если шо.

entity.fieldName

Об это сломано много копий. Я считаю что аксессоры лучше по многим причинам. Я говорил за стиль нейминга, а не за то, чтобы выбросить аксессоры.

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

Или мсье предлагает в сервисе

client.setName(client.getFullName());

? мсье знает толк.

Можно. Нужно ли — вопрос дискуссионный )

На правах оффтопа и ереси :). Меня вообще раздражают геттеры как таковые на уровне конвеншна. Я принципиально не согласен с неймингом getFieldName(), поскольку гет подразумевает какое-то активное действие, а геттер чаще всего это действительно просто доступ. С моей точки зрения, гораздо лучше писать просто entity.fieldName(), потому что 1) это отражает основную суть — доступ к проперти, а не какое-то содержательное действие. 2) ощутимо визуально сокращает код и уменьшает количество словКемелКейса.

Ооо, нажористый камент :) Бъет по наболевшему.

Кто вам сказал, что джава ограничивается поджо? Information expert pattern слышали?

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

Более того, оказывается, что в классе можно иметь много статических методов, которые приспособлены к stateless обработке структур данных внутри сущности. А то бывают граждане, которые считаю злом сам модификатор static.

Внезапно, оказывается, что сущность содержит внутреннюю логику, по поддержке собственного консистентного состояниия, для чего нам нужно явно контролировать, регистрировать или мутировать ее состояние на сетах. Вы хотите примеров? Их есть у меня. Представим Client, у которого есть поля name, firstName, middleName, lastName. При этом есть логика, согласно которой name = fN + mN + lN с пробелами. Вы конечно можеет сделать

clientService.concatAllNamesIn(client)

и засорить этим методом кучу строк в сервисе. И тем самым вы неправомерно отдадите ответственность за поддержание консистентного состояния кудато вовне, чем создадите error-prone design. А можете внедрить логику, там, где ей и место:

private void collectNames() { ... }

public void setFirstName(String fN) {
this.fN = fN;
this.collectNames(); *
}

* да, я знаю про нюанс с self-invocation и проксей. Но это является проблемой далеко не всегда. И на персистентных менеджед сущностях это как раз проблемой не является.

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

нужен очень высокий IQ

Астанавитесь ©

Просто быть лживым, жадным и подлым — не поможет.

Астанавитесь ©

100%. Когда ты сортируешь пластиковый мусор от пищевого, ты используешь экологию. Хотя может ты и батарейки в пищевой мусор выкидываешь, не особо удивлюсь.

Как мне это поможет в бизнесе?

Напрямую.

Никак?

Если бизнес по отжиманию барсеток или веб-макака, то да, никак.

чего я помочь в общество

Ехать лес пою? Как минимум это поможет мысли формулировать, с чем уже сейчас наблюдается проблема. Доп.эффект — откроет волшебный мир причинно-следственных связей в сфере «индивид-общество», с которыми тоже полная беда.

400$

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

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

А теперь он действительно верит, что земля плоская. Спрашивает, почему самолеты летают по карте не по прямой, считает что Арктика в центре диска, а Антакртида — вокруг. Всю современную космическую сферу считает ложью.

де ви застосували «філософське мислення»

Типичная проблема технаря, который считает какойнибудь сопромат вершиной развития человеческой мысли. Философия — это общий уровень культуры личности, как структурной единицы человеческой цивилизации. Если не попадал в общество, где могут спросить за культурку, то советую как-нибудь попасть, почувствовать себя отсталым лохом, и все-таки чтонибудь почитать.

Можно правда и дальше презирать все нетехническое и превращаться в некоммуникабельного социопата-затворника. Или вот реднеки — тоже екселент чойс.

Касательно екологии внизу я уже вспомнил про Трампа. Хороший пример. Человек стал президентом США, не знаю об изменениях климата в виду антропогенных факторов. Теперь пол-мира считает его необразованным дебилом, а в родной стране против его решений протестуют все научные круги, а сограждане фрустрируют от того, что он их президент.

Одна из проблем современной цивилизации в том, что она неправильно учит историю. Именно отсутствие изучения истории породило совок в 1917. Именно отсутствие изучения истории на должном уровне привело к тому, что существует миф «адиннарот», и прочие глобальные проблемы.

Так вот, отвечая на твой вопрос прямо — понимание экологии тебе нужно для того, чтобы не быть дибилом, который считает землю плоской, верит в ящериков, ЗОГ, считает углеводороды безальтернативным источником енергии, а глобальное потепление — мистификацией.

Посмотри на Трампа, который не в курсе за климатические изменения и поэтом против Парижских соглашений. Так вот, университетский курс экологии нужен чтобы ты не был человеком, от разговора с которым хочется укутаться в фейспалмы.

Делал стартап потратил 400$, идея была сделать сайт ухода за уличными плодовыми деревьями

А почему за уличными, почему не частными? У меня вот есть дача со старым яблонями, которые дряхлеют. Совсем недавно искал людей, которые могли бы их омолодить и поухаживать. Смог найти таких людей через друга, который работает в магазине спец.техники для садов. А так — я хз где заказать такую услугу.

Если бы был хипстерский сайт с красивой кнопкой «сделать деревьям хорошо», по нажатию на которую приехали бы люди и сделали хорошо, я б стал клиентом.

Так что возможно вы как-то не так развивали стартап. Хотя, возможно, рынок такой услуги и мал, или я просто не в курсе предложений.

Да у вас много свободного времени на работе, я смотрю )