Есть процедура "Создание заказа". Она вызывается только с id корзины, где есть список товаров. Есть бизнес-требование "Если есть товары из группы А, добавить дополнительную строку доставки 1000 рублей, потому что требуется грузчик". Его реализация это бизнес-логика. Вы это регулируете параметрами процедуры или if в коде процедуры?
Я добавлю эту дополнительную строку в список товаров корзины ПЕРЕД вызовом процедуры.
Процедура должна выполнять именно операцию создания заказа по переданному ей списку товаров с количествами и вернуть результаты своей работы (номер созданного заказа либо признак/код ошибки создания заказа). Это элементарная операция за пределами бизнес-логики. Добавление же строки - это бизнес-логика, которая реализуется в коде приложения, либо до вызова процедуры добавлением нужной строки в состав корзины (в процессе создания корзины в момент добавления в неё товара группы А, либо в момент финализации создания корзины и перехода к созданию заказа), либо после неё получением характеристик созданного заказа и вызовом процедуры корректировки заказа.
С кодом в приложении такого документирования требуется заметно меньше,
Вот этого не понимаю от слова "совсем". Есть "число 42". В документировании должна быть добавлена строка, которая разъясняет, что это за значение, куда и в каком случае пишется и т.п. Объясните мне, почему эта строка в документировании приложения будет короче. чем в документировании процедуры...
Или вы хотите сказать, что в процедуре это задокументировать нужно, а в приложении нет? Ну тогда мы снова возвращаемся к тому, что новый сотрудник дока в используемом ЯП (и так знает, что это за "42") и ноль в SQL.
какая-то процедура пишет в какую-то таблицу число 42, которое неизвестно что обозначает, и неизвестно кто его читает.
Ну то есть вся проблема - в хреновом документировании, что ли?
Процедура реализует правила и ограничения бизнеса - это бизнес-логика.
Вот только не надо тёплое да мягкое в одну кучу, да... Процедура реализует правила и ограничения, которые передаются в неё значениями параметров. Всё. Точка.
А вызов этой процедуры передаваемыми параметрами задаёт используемые ограничения и параметры применения правил в соответствии с требованиями бизнеса - вот сам вызов и есть бизнес-логика. Но он не на SQL сервере. а в вашем бизнес-приложении.
Вот если вы и параметры, необходимые бизнес-процессу, захардкодили в процедуре, то да, она как-то уже стала не общей процедурой, а куском вашей бизнес-логики. Но кто в том виноват-то?
Это связано с тем, что требования к качеству работы приложений возросли, а новых инструментов в SQL для решения этой проблемы так и не появилось, что не позволило повысить качество.
Невозможно относиться к подобным сентенциям иначе, чем к древнему "Кому сейчас нужна командная строка, если всё можно сделать мышкой". Инструмента, видите ли, нету...
Со временем, когда отцы-основатели данной хранимой процедуры покидают компанию, вместе с ними уходит и понимание того, как всё это должно функционировать. Новым сотрудникам, чтобы внести небольшие изменения, приходится собирать информацию по крупицам от тех, кто хоть как-то взаимодействовал с этим чудом инженерной мысли.
Переводя на русский - программист с хорошим знанием SQL уволился, а вместо него наняли другого, который в SQL ни ухом, ни рылом.
А виновата, как обычно, хранимая процедура.
Размазанность бизнес логики
Вот интересно, вас использование в бизнес-логике различных функций и процедур из "стандартных" библиотек не раскорячивает? Или если процедура поставляется с ОС/фреймворком/средой/прочее - то это built-in, а если сам написАл - то это бизнес-логика?
Любая бизнес-логика составлена из кучи элементарных операций. Сортировка, поиск, фильтрация, агрегация, расчёт, сравнение, выбор, и т.д., и т.п. И где-то есть та граница, после которой несколько последовательных элементарных операций становятся бизнес-логикой, специфической для конкретного процесса, хотя вот только что эта последовательность ещё была последовательностью достаточно стандартных операций, просто со специфическими константами, ограничениями и пр. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится. Просто отлаживать надо лучше, условий учитывать больше, входные проверять жёстче, документировать качественнее. Должно быть - "написал и забыл".
А SQL-сервер обрабатывает данные всяко лучше, чем программист напишет.
Одна крайность - просто сайт со списком мошеннических телефонных номеров и адресами фишинговых сайтов.
Другая крайность - все звонки и доступ в инет через их шлюзы, с авторизацией через госуслуги.
А вот вменяемой серединки-то я как-то не вижу... во всяком случае той, которую реально создать. Особенно если ещё захотеть, чтобы БР и прочие ФО компенсировали, случись что.
Так много слов, и практически ничего по делу. Считай, одна вода. А местами так и вовсе неверная информация. Например:
когда вы отправляете сообщение через Интернет, маршрутизаторы определяют оптимальный путь для передачи вашего сообщения от вашего компьютера до сервера получателя.
Да вот ни разу! Маршрутизатор никакие пути не строит и не сравнивает. В лучшем случае маршрутизатор определит, какой следующий узел, по его мнению, будет оптимален для передачи, и именно туда отправит пакет... а как путь этого пакета сложится дальше, ему глубоко пофиг.
даже если приложение не работает с диалоговым окном «не отвечает».
Поясните эту фразу. Что это за диалоговое окно такое? Я понимаю, если само приложение не отвечает операционной системе на запросы (по любой причине - сильно занято, или просто зависло), и ОС в заголовке окна приложения либо там в списке процессов рисует пометку "не отвечает". Но окно ... ?
функцию, которая позволяет завершать работу приложений непосредственно из панели задач.
Как именно работает эта функция? Это сразу безусловное закрытие приложения, или сначала ОС посылает приложению сигнал на закрытие, и только при отсутствии ожидаемой реакции выгружает его по жёсткому варианту?
Обрабатываются ли при этом диалоговые окна (например, предложение от приложения сохранить результат работы), или в подобных случаях приложение просто выгружается как зависшее?
есть ощущение, что переводили довольно плохим автопереводчиком
Да тут не ощущение, а просто-таки очевидность. Автоперевод, без проверки, кое-как (местами даже с ошибками) форматированный... плюс последующая ручная рихтовка (переделка скриншотов, конвертация их в код), выполненная, как говорится, "на отъ...сь", добавившая ещё солидную горсть ошибок.
Да и содержание местами весьма сомнительно. Если безальтернативное перечисление DDL/DML, с пропущенными TRUNCATE (DDL) и MERGE (DML) ещё как-то сойдёт, то подраздел с названием "ORDER BY Агрегаты" и вообще без ORDER BY - это явный косяк. А подраздел с названием "LATERAL Joins (хранимые процедуры)" - это вообще бред какой-то. Это всего лишь примеры.
Моё персональное мнение - качество представленного материала не стоило усилий по его публикации. Впрочем, и к оригиналу, не имеющему добавленных автором перевода проблем и ошибок, тоже есть изрядное количество претензий, но там хотя бы откровенных ляпов нет.
Важно понимать, что мы выполнили две транзакции параллельно и в результате получили неконсистентный результат.
Важная оговорка - полученный результат неконсистентный исключительно с точки зрения внешней для СУБД логики. А вот с точки зрения самого SQL сервера с данными всё в порядке - ибо у него нет такого правила согласованности данных, которое бы не допускало отсутствие в таблице хотя бы одной записи с on_call=true.
И вся вина за проблему - именно на кривом исполнении операции.
Причём тут хождение по граблям? Вам дали определённый стандартом формат, который содержит как значащие символы (в данном случае только цифры), так и шаблонные (как значащие - в данном случае префиксный плюс, так и незначащие - пробелы). Общеустоявшийся стандарт хранения настоятельно предлагает все эти символы при хранении значения удалять, а при извлечении соответственно вставлять. Так что комментарий по делу. Товарищ совершенно прав. Как в том, что плюс следует удалить так и в том, что это оптимизирует хранение и упрощает обработку.
в таком виде это описывается в литературе очень давних годов
Но мы-то живём не в те самые давние года... а если вам придёт в голову перепечатать так же кусок из книги 19 века, будете искать на клавиатуре еры да яти?
любительская литература обычно пишется для воспроизведения любителями, при этом информация сознательно упрощается и опускаются детали
... видимо, для того, чтобы не получилось воспроизвести?
Могу ещё предложить опубликовать аналогичным порядком какую-нибудь книжку по фотографии, годов пятидесятых, с рецептами проявителей - там непременно найдётся парочка составов, в которых применяется азотнокислый уранил. И можно будет похихикать над судьбой идиотов, которым придёт в голову попробовать собрать реактивы на такой рецептик.
На физическом уровне поляризация представляет собой покрытие поверхности положительного электрода большим количеством мелких пузырьков водорода
Чё? это вообще каким боком к поляризации? с каких это пор водород, да ещё в газообразном состоянии, стал проводником?
Появление пузырьков водорода на поверхности электрода приводит к вульгарному физическому блокированию поверхности электрода, уменьшению его эффективной площади и соответствующему снижению брутто-скорости реакции и скорости отдачи энергии. Чисто механическая причина.
Как было уже сказано, в качестве электролита используется желированный раствор следующего состава:
хлористый цинк — 0,5;
нашатырь — 1,0;
пшеничная мука — 1,0;
вода — 5,0.
Не, уж коли берётесь за описание процесса с претензией на то, что его можно воспроизвести - то описывайте точно. Нет такого вещества "нашатырь". Так в просторечии называют водный раствор аммиака. Который может иметь к тому же разную концентрацию, например, в аптеках обычно продаётся раствор с концентрацией 10%. Хлорид цинка - это какой? Количество указано в пересчёте на сухое вещество? он же жрёт влагу из воздуха как не в себя! И для желирования лучше использовать более подходящие реактивы, чем мука. Например, агар куда как лучше подойдёт, да и грязи (с химической точки зрения) в нём куда как меньше. И да - кипятить раствор аммиака, пусть и с дополнительными компонентами, и надеяться, что там что-то не улетит - это ну очень оптимистично.
Так что прежде чем списывать непонятно что непонятно откуда - попробуйте сами всё это проделать. К тому моменту, как хоть что-то получится, уже статью писать авось и расхочется.
Дальше даже читать не стал, сто пудов там такие же народные сказки.
Каждому сетевому устройству присвоен свой MAC-адрес.
Не, всё ещё хуже. К одному сетевому устройству (скажем, проводной сетевой карте) может быть привязана хренова гора логических интерфейсов. И каждый может (и скорее всего будет) иметь свой собственный оригинальный МАС.
Наиболее показательный пример - виртуальные машины, подключаемые к одному сегменту сети через один проводной физический интерфейс и один логический сегмент виртуального коммутатора гипервизора, работающий в режиме моста.
Я добавлю эту дополнительную строку в список товаров корзины ПЕРЕД вызовом процедуры.
Процедура должна выполнять именно операцию создания заказа по переданному ей списку товаров с количествами и вернуть результаты своей работы (номер созданного заказа либо признак/код ошибки создания заказа). Это элементарная операция за пределами бизнес-логики. Добавление же строки - это бизнес-логика, которая реализуется в коде приложения, либо до вызова процедуры добавлением нужной строки в состав корзины (в процессе создания корзины в момент добавления в неё товара группы А, либо в момент финализации создания корзины и перехода к созданию заказа), либо после неё получением характеристик созданного заказа и вызовом процедуры корректировки заказа.
Вот этого не понимаю от слова "совсем". Есть "число 42". В документировании должна быть добавлена строка, которая разъясняет, что это за значение, куда и в каком случае пишется и т.п. Объясните мне, почему эта строка в документировании приложения будет короче. чем в документировании процедуры...
Или вы хотите сказать, что в процедуре это задокументировать нужно, а в приложении нет? Ну тогда мы снова возвращаемся к тому, что новый сотрудник дока в используемом ЯП (и так знает, что это за "42") и ноль в SQL.
Ну то есть вся проблема - в хреновом документировании, что ли?
Вот только не надо тёплое да мягкое в одну кучу, да... Процедура реализует правила и ограничения, которые передаются в неё значениями параметров. Всё. Точка.
А вызов этой процедуры передаваемыми параметрами задаёт используемые ограничения и параметры применения правил в соответствии с требованиями бизнеса - вот сам вызов и есть бизнес-логика. Но он не на SQL сервере. а в вашем бизнес-приложении.
Вот если вы и параметры, необходимые бизнес-процессу, захардкодили в процедуре, то да, она как-то уже стала не общей процедурой, а куском вашей бизнес-логики. Но кто в том виноват-то?
Да, обязательно. Это составная часть контроля входных данных. Переданные координаты не должны выходить за границы.
Невозможно относиться к подобным сентенциям иначе, чем к древнему "Кому сейчас нужна командная строка, если всё можно сделать мышкой". Инструмента, видите ли, нету...
Переводя на русский - программист с хорошим знанием SQL уволился, а вместо него наняли другого, который в SQL ни ухом, ни рылом.
А виновата, как обычно, хранимая процедура.
Вот интересно, вас использование в бизнес-логике различных функций и процедур из "стандартных" библиотек не раскорячивает? Или если процедура поставляется с ОС/фреймворком/средой/прочее - то это built-in, а если сам написАл - то это бизнес-логика?
Любая бизнес-логика составлена из кучи элементарных операций. Сортировка, поиск, фильтрация, агрегация, расчёт, сравнение, выбор, и т.д., и т.п. И где-то есть та граница, после которой несколько последовательных элементарных операций становятся бизнес-логикой, специфической для конкретного процесса, хотя вот только что эта последовательность ещё была последовательностью достаточно стандартных операций, просто со специфическими константами, ограничениями и пр. И если эта последовательность переносится в хранимую процедуру, то бизнес-логика совершенно не страдает и не дробится. Просто отлаживать надо лучше, условий учитывать больше, входные проверять жёстче, документировать качественнее. Должно быть - "написал и забыл".
А SQL-сервер обрабатывает данные всяко лучше, чем программист напишет.
Логической-то может и нет, а вот идеологическая присутствует.
Любой ввод должен быть проверен. Особенно интерактивный.
Одна крайность - просто сайт со списком мошеннических телефонных номеров и адресами фишинговых сайтов.
Другая крайность - все звонки и доступ в инет через их шлюзы, с авторизацией через госуслуги.
А вот вменяемой серединки-то я как-то не вижу... во всяком случае той, которую реально создать. Особенно если ещё захотеть, чтобы БР и прочие ФО компенсировали, случись что.
Знаю только четверть. Убеждён, что лично мне из всех этих сайтов нужны .. чуть меньше чем один.
Пожалуй, присоединюсь к Вашему счастливому неведению...
Так много слов, и практически ничего по делу. Считай, одна вода. А местами так и вовсе неверная информация. Например:
Да вот ни разу! Маршрутизатор никакие пути не строит и не сравнивает. В лучшем случае маршрутизатор определит, какой следующий узел, по его мнению, будет оптимален для передачи, и именно туда отправит пакет... а как путь этого пакета сложится дальше, ему глубоко пофиг.
Сколько слов - и ничего по делу. Одна вода. Даже рекламой, и то не обозвать...
Поясните эту фразу. Что это за диалоговое окно такое? Я понимаю, если само приложение не отвечает операционной системе на запросы (по любой причине - сильно занято, или просто зависло), и ОС в заголовке окна приложения либо там в списке процессов рисует пометку "не отвечает". Но окно ... ?
Как именно работает эта функция? Это сразу безусловное закрытие приложения, или сначала ОС посылает приложению сигнал на закрытие, и только при отсутствии ожидаемой реакции выгружает его по жёсткому варианту?
Обрабатываются ли при этом диалоговые окна (например, предложение от приложения сохранить результат работы), или в подобных случаях приложение просто выгружается как зависшее?
Да тут не ощущение, а просто-таки очевидность. Автоперевод, без проверки, кое-как (местами даже с ошибками) форматированный... плюс последующая ручная рихтовка (переделка скриншотов, конвертация их в код), выполненная, как говорится, "на отъ...сь", добавившая ещё солидную горсть ошибок.
Да и содержание местами весьма сомнительно. Если безальтернативное перечисление DDL/DML, с пропущенными TRUNCATE (DDL) и MERGE (DML) ещё как-то сойдёт, то подраздел с названием "ORDER BY Агрегаты" и вообще без ORDER BY - это явный косяк. А подраздел с названием "LATERAL Joins (хранимые процедуры)" - это вообще бред какой-то. Это всего лишь примеры.
Моё персональное мнение - качество представленного материала не стоило усилий по его публикации. Впрочем, и к оригиналу, не имеющему добавленных автором перевода проблем и ошибок, тоже есть изрядное количество претензий, но там хотя бы откровенных ляпов нет.
Важная оговорка - полученный результат неконсистентный исключительно с точки зрения внешней для СУБД логики. А вот с точки зрения самого SQL сервера с данными всё в порядке - ибо у него нет такого правила согласованности данных, которое бы не допускало отсутствие в таблице хотя бы одной записи с
on_call=true.И вся вина за проблему - именно на кривом исполнении операции.
Нет, именно в составе проявителя.
К сожалению, сама книжка не сохранилась.
Причём тут хождение по граблям? Вам дали определённый стандартом формат, который содержит как значащие символы (в данном случае только цифры), так и шаблонные (как значащие - в данном случае префиксный плюс, так и незначащие - пробелы). Общеустоявшийся стандарт хранения настоятельно предлагает все эти символы при хранении значения удалять, а при извлечении соответственно вставлять. Так что комментарий по делу. Товарищ совершенно прав. Как в том, что плюс следует удалить так и в том, что это оптимизирует хранение и упрощает обработку.
Но мы-то живём не в те самые давние года... а если вам придёт в голову перепечатать так же кусок из книги 19 века, будете искать на клавиатуре еры да яти?
... видимо, для того, чтобы не получилось воспроизвести?
Могу ещё предложить опубликовать аналогичным порядком какую-нибудь книжку по фотографии, годов пятидесятых, с рецептами проявителей - там непременно найдётся парочка составов, в которых применяется азотнокислый уранил. И можно будет похихикать над судьбой идиотов, которым придёт в голову попробовать собрать реактивы на такой рецептик.
Чё? это вообще каким боком к поляризации? с каких это пор водород, да ещё в газообразном состоянии, стал проводником?
Появление пузырьков водорода на поверхности электрода приводит к вульгарному физическому блокированию поверхности электрода, уменьшению его эффективной площади и соответствующему снижению брутто-скорости реакции и скорости отдачи энергии. Чисто механическая причина.
Не, уж коли берётесь за описание процесса с претензией на то, что его можно воспроизвести - то описывайте точно. Нет такого вещества "нашатырь". Так в просторечии называют водный раствор аммиака. Который может иметь к тому же разную концентрацию, например, в аптеках обычно продаётся раствор с концентрацией 10%. Хлорид цинка - это какой? Количество указано в пересчёте на сухое вещество? он же жрёт влагу из воздуха как не в себя! И для желирования лучше использовать более подходящие реактивы, чем мука. Например, агар куда как лучше подойдёт, да и грязи (с химической точки зрения) в нём куда как меньше. И да - кипятить раствор аммиака, пусть и с дополнительными компонентами, и надеяться, что там что-то не улетит - это ну очень оптимистично.
Так что прежде чем списывать непонятно что непонятно откуда - попробуйте сами всё это проделать. К тому моменту, как хоть что-то получится, уже статью писать авось и расхочется.
Дальше даже читать не стал, сто пудов там такие же народные сказки.
Плюс несколько грубых фактических ошибок.
Конечно, можно. XML - это же текст. Текстовых функций в постгрессе - вагон и маленькая тележка, распарсить можно что угодно и как угодно.
Хотя это дурь, конечно. Ибо в Постгрессе есть и горсть XML-функций. В том числе XMLTABLE().
Не, всё ещё хуже. К одному сетевому устройству (скажем, проводной сетевой карте) может быть привязана хренова гора логических интерфейсов. И каждый может (и скорее всего будет) иметь свой собственный оригинальный МАС.
Наиболее показательный пример - виртуальные машины, подключаемые к одному сегменту сети через один проводной физический интерфейс и один логический сегмент виртуального коммутатора гипервизора, работающий в режиме моста.
Нет, просто шлюз - это наиболее "яркая" характеристика из параметров сети. Как пример.