Гулин Федор

PaulWist

Вывод:
а) переносим бизнес логику на уровень БД.
б) из клиента вызываем только ОДНУ (мастер) ХП.
в) используем клиентскую транзакцию только для заполнения промежуточных сущьностей необходимых для работы мастер ХП.

это как бы оффтоп - но мне интересно - думаю может еще кому
с а) ок - допустим решили и делаем так.
б) - имеется ввиду ОДНА мастер SP для сохранения данных
- одна в принципе вообще ??
и пример (я надеюсь в T-sql) наименования , Параметров , и пример вызова
мне не очень понятна универсальность и как это реально может работать

про в) я честно тоже не понял - можно сюда же всунуть в ответ пример чего и как.

Конечно, "мастер" ХП своя для каждого бизнес процесса, как предлагает Александр, например ХП СохранитьДокумент - реализует запись в БД мастер-детали документа, те для каждого процесса своя ХП включающая бизнес логику процесса.

Pekpytep
но теперь возможностей накосячить меньше и на стороне бд больше возможностей быстро найти и ликвидировать ошибку.

Вот это утверждение крайне сомнительно. Оно справедливо только в одном случае, если программисты, пишущие SP, по своему уровню существенно превосходят программистов на java. Накосячить легко можно и там, и там. А возможностей быстро найти и ликвидировать ошибку на java ничуть не меньше. К тому же у java есть одно большое преимущество: OOP, что позволяет в разы сократить количество кода, а, соответственно, и времени на разработку. Как я понял, у ТС проблема именно в разнице уровней программистов SQL vs java. Но это проблема административная, и решать ее лучше административными методами, а не программистскими.

leonid
Как я понял, у ТС проблема именно в разнице уровней программистов SQL vs java. Но это проблема административная, и решать ее лучше административными методами, а не программистскими.

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

PaulWist
Тут скорее проблема архитектуры, которая изначально выбрана "косовато"

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

С моей точки зрения "управляет" та сторона, которая дает команды на управление.

Если я пишу try..catch на клиенте, то "управлением" занимается собственно клиент. Именно клиент определяет куда именно я попаду в случае возникновения исключительной ситуации. Вот где я на клиенте catch написал, туда и перейду при исключении

Если же обработкой занимается ХП на сервере, то только ХП сервера она и управляет. Вне этой ХП она ничего "не знает". И никак, никоим образом, не может определить, куда произойдет переход на стороне клиента

Ну, для примера


Разве ХП SQL может как-то определить, куда именно произойдет переход в клиенте в случае возникновения исключения внутри ХП? Ну, например, не выполнять "Команду 2"? Нет конечно! Этим должен озаботится сам клиент. А это и означает отсутствие управления со стороны сервера.

Т.е. сервер не может управлять клиентом. Никак. Значит полноценный контроль транзакции на уровне сервера в рамках распределенного приложения - невозможен. Имею в виду ситуацию, когда код модификации "распределен" по разным уровням приложения

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

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

Речь не идёт о клиентских транзакциях как таковой.

ТС говорит о том, что в клиентской транзакции производится вызов НЕСКОЛЬКИХ ХП у которых не обрабатываются коды возврата, в итоге получается "каша" в данных не соответствующая бизнес процессу.

Выполнения ХП на стороне СУБД имеет 2 составляющих, код возврата выполнения ХП (return) и код ошибки с соответствующими действиями по нему.

Анализ кода возврата ХП - если прогер не сделал его анализ, то не важно на клиенте или в ХП это произошло, косяк останется косяком.

А вот если в ХП произошла ошибка, даже если прогер не обработает её, то как правило СУБД автоматом не даст сохранить данные и выбросит исключение игнорируя дальнейший код (команды DML, вызовы ХП итд), что по словам ТС на клиенте не делается/забывается.
Таким образом убирается целый слой ошибок связанный с "правильностью" бизнес процессов.

Ну так это не косяк архитектуры, а косяки реализации.

leonid
Вот это утверждение крайне сомнительно. Оно справедливо только в одном случае, если программисты, пишущие SP, по своему уровню существенно превосходят программистов на java

Так и есть. В основном на проекте задействованы старшие/ведущие разработчики БД, средний возраст 35-45 лет, которые повидали множество проектов и СУБД. Джависты же в основном - молодежь после института. Даже о профессионализме тех немногих возрастных джава-разработчиков затрудняюсь судить исходя из того треша и угара, который происходит. )
Не знаю как в Прибалтике, а в РФ наблюдается дефицит вменяемых джава-разработчиков, которые реально, а не в теории что-то умеют. И ценник у них негуманный, зачастую конторы предпочитают экономить.

leonid
Помещать бизнес логику в средний слой на java, и упрвлять оттуда транзакциями - это вполне стандартное решение.

Никто и не спорит что нормальное, если изначально делать по уму. Проблема в том что весь DML на стороне БД, а управление транзакциями на среднем слое. 90% бизнес-логики тоже на бд (и тоже наверное из-за недостатка нормальных джава-разработчиков). Собственно клиенту доступны только вью только для чтения и все что делается на стороне клиента - привязка вьюх к гридам да select count(*) from view для пейджинга. Нет никаких прямых запросов в таблицы и тем более модификации данных.
На самом деле никто нигде ничего не собирается изменять и переносить. Теория с парадигмами - наше всё. Будем конечно же колоться, плакать но продолжать жрать кактус говнокодить. Но не просто говнокодить, а говнокодить в строгом соответствии с корпоративными политиками, парадигмами и теорией трехзвенной архитектуры.
Так что воспринимайте этот топик как мои больные фантазии на тему "а что было бы если..."

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

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

leonid
Ну так это не косяк архитектуры, а косяки реализации.

Одно вытекает из другого, неправильная архитектура ведёт к соотвествующей реализации.

Более того, я прекрасно понимаю ТС, сам (и не один) "ковыряю" проект, которому 20 лет, ... транзакций нет, FK нет, ХП нет, констрейнтов нет, триггеров нет ... есть PK но они не используются, есть default-ы правда тоже кривые, те проект аля FPD, но с гордым названием клиент-сервер .
И хоть ты убейся, кривая архитектура приводит к кривой реализации! (а что там в данных творится - это караул :lol





Исправлено 2 раз(а). Последнее : PaulWist, 29.05.20 11:20

Владимир Максимов
С моей точки зрения "управляет" та сторона, которая дает команды на управление.
Если я пишу try..catch на клиенте, то "управлением" занимается собственно клиент. Именно клиент определяет куда именно я попаду в случае возникновения исключительной ситуации. Вот где я на клиенте catch написал, туда и перейду при исключении

try..catch на клиенте - ловит ошибки клиента!

try..catch на сервере - ловит ошибки сервера!

Таким образом, об ошибках сервера клиент не знает вообще ничего, вернее так если не анализировать код возврата ХП, что там произошло на сервере клиент не знает.

Владимир Максимов

Если же обработкой занимается ХП на сервере, то только ХП сервера она и управляет. Вне этой ХП она ничего "не знает". И никак, никоим образом, не может определить, куда произойдет переход на стороне клиента

Ну, для примера

Клиент
   Команда 1
      Вызов ХП SQL - внутри произошло исключение
   Команда 2

Разве ХП SQL может как-то определить, куда именно произойдет переход в клиенте в случае возникновения исключения внутри ХП? Ну, например, не выполнять "Команду 2"? Нет конечно! Этим должен озаботится сам клиент. А это и означает отсутствие управления со стороны сервера.

Конечно, если клиент не смотрит на коды возврата, то ХП сервера никак не управляет поведением клиента, а если смотрит, то ХП напрямую определяет поведение клиента.

Владимир Максимов

Т.е. сервер не может управлять клиентом. Никак. Значит полноценный контроль транзакции на уровне сервера в рамках распределенного приложения - невозможен. Имею в виду ситуацию, когда код модификации "распределен" по разным уровням приложения

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

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

PaulWist
неправильная архитектура ведёт к соотвествующей реализации.

Безусловно, но у ТС другой случай.

WbrErr

PaulWist

WbrErr
А совет представителя Майкрософт Цингауза на этом форуме не применять клиентские транзакции опять все забыли?

Специфическая, но рассматривается.
forum.foxclub.ru

Похоже ты не понял про что писал Алексей...
А писал он про смешивание 2 методик управления транзакциями - явная отсылка "текстом" команд begin trans/commit/rollback, и управление через вызов соответствующего АПИ, которое в фоксе для ODBC источников реализуется через SQLSETPROP("Trans")/SQLCOMMIT()/SQLROLLBACK().
И писал он про то что первый вариант сложнее и лучше его не применять, а второй как раз и есть рекомендованный. И это всё для случая когда транзакциям в принципе надо управлять, т.к. "по умолчанию" фокс настроен на режим автоматических транзакций, а это значит что по сути после каждой команды будет выполняться "подтверждение транзакции".

Pekpytep
При управлении транзакциями на стороне бд вероятность нарушения целостности данных сильно меньше.

СУБД имеющая транзакции (оракл, мсскл, мускл, постгре и масса иных подобных) в принципе никогда не работает "вне транзакций". Управляешь ты ими или нет (настроен автомат того или иного рода) - в любом случае любая модификация данных производится в рамках транзакции. И эти транзакции, вкупе со всеми другими механизмами СУБД обеспечивают "сохранение целостности".
Естественно речи не идёт про "логическую непротиворечивость" - как только речь заходит про "логику", тут уже всё целиком и полностью в руках разработчика прикладного ПО. Пока ещё не придумали ИИ который бы за разработчика решал какие операции должны выполниться "все или ничего", какие же вполне могут коммитится по отдельности.

Pekpytep
Вопрос в том, возможно ли решить часть организационных проблем за счет частичного изменения архитектуры

Нет. Организацонные вопросы никогда и нигде не решаются программными мерами.
При этом выбор архитекутры приложения это как раз организационный вопрос, а не программный

Pekpytep
Во-первых, что управление транзакциями на стороне БД не является крамолой или преступлением как пытаются мне "доказать" некоторые мои коллеги.

Как раз таки является во многих случаях.
То что касается бизнес-логики - должно управляться оттуда, где эта самая бизнес-логика реализуется. Если у тебя вся логика в БД - есть, грубо говоря, лишь внешний интерфейс в виде ХП с чётко описанным правилом - "то что было запрошено отменить уже нельзя" - то это одно. Если же у тебя в ХП лишь часть бизнес-логики, при том лишь самая базовая, типа "сумма не должна быть <0, код клиента должен быть в справочнике, удаление записи шапки должно вызывать каскадное удаление связанных записей строк", то крайне маловероятно что управлять транзакциями должны такие "кусочки логики". Они не видят целой картины, не имеют всех взаимосвязей (ну к примеру что уменьшение баланса счёта 1, увеличение баланса счёта 2 и создание записи о проведенной операции должны быть либо все сделаны, либо ни одно изменение не должно быть сохранено).

Pekpytep
Весь первый блок из 8 пунктов вкладываем внутрь процедуры p_save_button, которая на стороне бд будет рулить транзакциями, анализировать код ошибки и фиксировать/откатывать изменения.

Ну ты переходишь к варианту переноса ВСЕЙ бизнес-логики на сторону БД. А так уже давно стараются не делать по куче самых разных причин.
Я тоже не вижу ничего хорошего в мега-БД в паре с примитивным средним слоем и не менее "тупым" UI.

Заменяешь условного Джавашута на условного Оралега, который должен "правильно написать последовательность действий, сформулировав корректную единицу работы". Дорого и неэффективно IMHO. Проще учить разработчиков среднего слоя - решать организационный вопрос организационным методом

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

P.S. если бы я был на месте твоих джавистов, то двумя руками бы голосовал за твоё предложение. Ты на 50-70% забираешь их работу, и на 99% забираешь ответственность
Клепать примитивнейшую прослойку между UI и ХП с 0% логики, ещё и не нести никакой ответственности за возникающую хрень в БД (а я тебя уверяю, количество хрени не сильно уменьшится как джависты забивали/забывали защищённо и надёжно писать, так и ораклисты будут делать, увеличь ты им работу в 2-3 раза).

PaulWist
Тут скорее проблема архитектуры, которая изначально выбрана "косовато" (те как умели так и начали писать), а если проект большой и живёт приличное время, то изменить в нём что-то очень проблематично, как правило на рефакторинг нет ресурсов.

Честно говоря, я не встречал проектов где вся логика была бы реализована на ХП, а клиент/промежуточный слой были бы предельно просты. И это точно не мэйнлайн современной разработки.
На ум приходят лишь системы типа оракловских Forms (насколько я в курсе - успешно похоронены), Apex (вроде даже изначально не позиционировался для "корпоративной разработки" - вообще по сути всё-в-одном-и-это-СУБД), или те же "веб-сервисы средствами СУБД" (тоже как-то не прижились).
Я не говорю что это нереализуемо, или тем паче "неправильно" - но по факту так не делают, а значит на то есть причины...

> я не встречал проектов где вся логика была бы реализована на ХП,
() а советы по моему проекиу именно такие "сделай на современной основе, до какого фига ты не сделал"...
Идоты, оба.

не мешаю
() подпрограммы (и функции "возвращяющие знвчение") - это и есть "программирование", Какого фига вам еще надо, каких теорий?
Будеву алгебру хоть освоили? "а + б + с" сможете инвертировать?

Булеву, паардон ))) () Иностранное слово...



Исправлено 3 раз(а). Последнее : of63, 31.05.20 01:20

Igor Korolyov
Я не говорю что это нереализуемо, или тем паче "неправильно" - но по факту так не делают, а значит на то есть причины...

Конечно есть причины, кто тут спорит, как умел стартап делать так и начали реализовывать, а потом что-то менять уже себе дороже.

Я видел две системы (в одной из них участвовал) где вся логика в БД.

И да, действительно back-end-у приходилось платить достойные деньги, а с front-end справлялись студенты.

Igor Korolyov
Похоже ты не понял про что писал Алексей...
А писал он про смешивание 2 методик управления транзакциями - явная отсылка "текстом" команд begin trans/commit/rollback, и управление через вызов соответствующего АПИ, которое в фоксе для ODBC источников реализуется через SQLSETPROP("Trans")/SQLCOMMIT()/SQLROLLBACK().
И писал он про то что первый вариант сложнее и лучше его не применять, а второй как раз и есть рекомендованный. И это всё для случая когда транзакциям в принципе надо управлять, т.к. "по умолчанию" фокс настроен на режим автоматических транзакций, а это значит что по сути после каждой команды будет выполняться "подтверждение транзакции".

В курсе, в курсе.

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

Igor Korolyov
СУБД имеющая транзакции (оракл, мсскл, мускл, постгре и масса иных подобных) в принципе никогда не работает "вне транзакций".

Тут ты для MySQL заблуждаешься, таблицы MYISAM не поддерживают транзакции (во всяком случае в той редакции MySQL в которой я ковыряюсь)





Исправлено 1 раз(а). Последнее : PaulWist, 31.05.20 11:08

Насколько я понимаю, MySQL использует транзакции в любом случае, просто для таблиц в формате (или как там правильно сказать - обслуживающихся драйвером...) не поддерживающем транзакционную целостность появляются "нехорошие нюансы".
Если я не ошибаюсь, то точно такая же беда будет для МС и оракла, если там какие-нить "внешние таблицы" попытаться задействовать, "драйвер доступа" к которым, или они сами не поддерживает транзакционной целостности.

ну было интересно
каждый писал на основе своего опыта - но почитать было интересно

я сейчас на суппорте старой системы web+Oracle (и даже не знаю 2-звенка или 3 звенка - скорее 2-х все таки)
по DB части только

я добавлю один плюс когда часть логики сидит в оракл. пакетах

мне иногда надо писать Mass Update скрипты - и наличие тех самых пакетов позволяет юзать их
а не писать все через DML (ибо там навороченная логика - а так написал pack1.createNewVersion , ... и уже проще
(И да через курсоры приходится - но там не огромные объемы данных - поэтому не проблема)

и собвственно 2 сторона этой же медали - когда надо вдруг чего то создать вручную (или скажем для тестов)
то имхо с стороны БД это сделать проще
я вот слабо представляю как допустим с java app можно дернуть
(хотя допускаю что там через веб-сервисы торчащие снаружу это возможно
и у нас даже есть такие вещи - но там иногда надо сувать скажем некоторые вещи в json body а это сильно геморно )

Ps я подозреваю что знай я хорошо клиент.софт и если бы писал один я бы тоже не размазывал логику по БД и App а сувал бы почти все в App

Гулин Федор
... я бы тоже не размазывал логику по БД и App а сувал бы почти все в App

И PK, FK, default, unuque constraint, permission object/users/database итд тоже через App поддерживал бы.