Лучшие языки, чем SQL для [закрытых] хранимых процедур
То, что я хотел бы - выполнить все из них (чтобы все они печатали все ошибки) и только потом потерпеть неудачу
blockquote>По сути, у нас есть список кодов выхода, которые нужно перехватить. Если какой-либо из них ненулевой, нам нужно установить переменную, которая будет иметь ненулевое значение. Расширение этого до списка выглядело бы так:
result=0 if ! lint_1; then result=1; fi if ! lint_2; then result=1; fi if ! lint_3; then result=1; fi exit "$result"Как программист, я вижу, что здесь у нас есть образец. Таким образом, мы можем использовать массив, но bash не имеет двухмерных массивов. Это был бы обходной путь с
evalдля обхода указанных параметров. Это выполнимо. Вы должны использоватьeval, чтобы дважды вычислить массив «указатель» / имя, но работает. Обратите внимание, чтоevalэтоevil.cmds_1=(lint_1 "arg with spaces you pass to lint_1") cmds_2=(lint_2) cmds_3=(lint_3) result=0 # compgen results list of variables starting with `cmds_` # so naming is important for i in $(compgen -v cmds_); do # at first, `$i` is only expanded # then the array is expanded `"${cmds_?[@]}"` if ! eval "\"\${$i[@]}\""; then result=1 fi done exit "$result"Мы также можем пойти с xargs . Из руководства
EXIT STATUSесть123 if __any__ invocation of the command exited with status 1-125. Если вы знаете, что ваши программы будут выходить из состояния выхода 1-125, вы можете (обычно xargs в любом случае корректно обрабатывает различные состояния выхода (возвращает 123), но давайте оставаться в соответствии):xargs -l1 -- bash -c '"$@"' -- <, что выглядит странно чисто. Кстати, передав только
-Pвxargs, вы можете выполнить всю команду параллельно. Вы можете приспособиться к диапазону ошибок 1-125, обработав ошибку внутри скрипта bash, т. Е.xargs -l1 -- bash -c '"$@" || exit 1' -- <И у меня есть другая идея. После каждой команды мы можем вывести возвращаемый статус по выделенному файловому дескриптору. Затем из всех возвращаемых статусов отфильтруйте нули и проверьте, есть ли в потоке другие статусы. Если они есть, мы должны выйти с ненулевым статусом. Это похоже на проделанную работу и в основном соответствует первому фрагменту кода, но
if ! ....; then result=1; fiупрощено до; echo $? >&10.tmp=$(mktemp) ( lint_1 "arg with spaces you pass to lint_1"; echo $? >&10 lint_2; echo $? >&10 lint_3; echo $? >&10 ) 10> >( [ -z "$(grep -v 0)" ] echo $? > "$tmp" ) result="$(cat "$tmp"; rm "$tmp")" exit "$result"Из представленных вариантов я бы пошел с другим ответом;) или со вторым отсеченным xargs.
7 ответов
Существуют некоторые архитектурные препятствия наличию более умных языков запросов в менеджере базы данных. Основной является оптимизатором запросов. Одно из конструктивных ограничений на SQL - то, что он может только использовать конструкции, которые доступны для оптимизатора запросов. Это означает, что язык и его возможности вполне сильно связываются к возможностям механизма выполнения запросов и оптимизатора плана запросов.
Другое основное конструктивное ограничение является механической природой системы баз данных - программирование базы данных почти уникально в этом, это имеет механический компонент. Производительность запросов ограничена механическими ограничениями головки диска, ищет и вращательная задержка (время ожидания перед, данные, которые Вы хотите, прибывают под головами).
Это эффективно устраняет много умных абстракций, которые могли бы сделать SQL более мощным или легче работать с. Много систем управления базами данных добавляют SQL с процедурными альтернативами, которые могут использоваться для сценариев. Однако они взаимодействуют с DBMS путем выполнения ряда SQL-запросов, которые обрабатываются оптимизатором индивидуально. Некоторые языки этого типа, которые поставляются с различными платформами DBMS:
Oracle МН / SQL и встроенный Java. МН / SQL на самом деле основан на Ada - это - вполне 'старая школа' по современным стандартам и имеет основу унаследованного кода, с которой это должно остаться backwardly совместимый. Это - не обязательно самая приятная среда программирования, но это действительно имеет конструкции для средств, таких как параллелизм и довольно гибкая система типов. Одно из основных критических замечаний хранимых процедур Java на Oracle - то, что Вы платите за основанное на способности лицензирование Oracle на ЦП, Вы работаете на JVM.
SQL Server Интеграция CLR. Несколько подобный Хранимым процедурам Java Oracle, это позволяет модулям CLR, скомпилированным от C# (или любой язык .NET) быть загруженными в экземпляр SQL Server и выполненными почти таким же способом как хранимые процедуры. SQL Server также имеет PostgreSQL-стиль API для того, чтобы сделать пользовательские агрегатные функции через интеграцию CLR и другие рычаги для смешанных кодовых баз SQL/CLR.
PostgreSQL является на самом деле системой, где интеграция языка бэкенда была первоначально разработана. Система экспортирует собственный API C со средствами для пользовательских агрегатных функций, механизмами устройства хранения данных, процедурными расширениями и другой функциональностью. Интерфейсы языка основаны на этом API и включают: PL/pgSQL (сделанный на заказ язык, подобный МН / SQL), Python, Perl и Tcl.
Это превратило его в господствующую тенденцию через Illustra, коммерциализированную версию Пост-ГРЭС, которая была затем выкуплена Informix (который был впоследствии выкуплен IBM). Основные характеристики были включены в Informix Онлайн, который все еще продается IBM.
Одно ключевое ограничение этих языков является их ограниченным взаимодействием с оптимизатором запросов (хотя API C для PostgreSQL действительно имеет поддержку этого). Участие в плане запросов как первоклассный гражданин требует, чтобы оптимизатор запросов мог разработать разумное представление ресурсов, которые возьмет Ваше действие. На практике этот тип взаимодействия с оптимизатором запросов главным образом полезен для реализации механизмов устройства хранения данных.
Этот уровень рытья в механизм устройства хранения данных (a) несколько тайный, если функциональность доступна вообще (таким образом, у большинства людей не будет навыка, чтобы сделать это), и (b) вероятно, considrably больше проблемы, чем просто запись запроса в SQL. Ограничения оптимизатора запросов означают, что Вы никогда не будете, вероятно, вытаскивать уровень абстракции из SQL, от которого Вы могли бы добраться (говорят) что Python или даже C# или Java.
Путь наименьшего сопротивления для эффективных запросов, вероятно, будет писать запрос в SQL с небольшим количеством процедурного связующего звена на одном из других языков. В некоторых случаях вычисление действительно предоставляет себя процедурному подходу.
Это может стать стычкой и привести к большим телам шаблонного кода SQL. Единственные реальные опции для этого являются рукой, кодированной системы генерации кода или SQL. Тривиальным примером генерации кода является функциональность CRUD, обеспеченная платформами, где этот SQL сгенерирован от метаданных. Более сложный пример виден в инструментах ETL, таких как Складской Разработчик Oracle или Красный Wherescape, которые работают путем генерации больших перечислений кода хранимой процедуры из модели.
Я нахожу меня системами поколения строительных норм и правил одного вида или другого на полурегулярной основе по точно этой причине. Любая система шаблонной обработки сделает для этого - у меня был довольно экономичный расход топлива от CherryTemplate, но вокруг существует много таких объектов. Генерация кода в Действии является вполне хорошей книгой по этому предмету - автор использует основанную на рубине систему, имя которой выходит из меня.
Править: При рассмотрении 'Шоу Предполагаемый План выполнения', относительно блока процессуального кода Вы заметите, что каждый оператор имеет свой собственный план запросов. Алгоритм оптимизации запросов может только работать над единственным SQL-оператором, таким образом, процедура будет иметь лес планов запросов. Поскольку процессуальный кодекс может иметь 'побочные эффекты', Вы не можете использовать тип алгоритмов, используемых в оптимизации запросов для обоснования о коде. Это означает, что оптимизатор запросов не может глобально оптимизировать блок процессуального кода. Это может только оптимизировать отдельные SQL-операторы.
PostgreSQL имеет поддержку многих процедур языков сценариев. Официально Perl, Python и Tcl. Как дополнения, PHP, Ruby, Java и вероятно многие другие (просто Google для мн <languagename>), который может или не может быть в исправном состоянии на данный момент.
О, и также SQL Server, 2005 вперед имеет поддержку хранимых процедур CLR, где можно использовать языки.NET.
Oracle действительно поддерживает хранимые процедуры CLR, таким образом, можно записать сохраненный procs на любом языке.NET как C#, VB.NET или IronPython. Это только работает, когда сервер базы данных работает на машине Windows. Вы не можете сделать этого, когда база данных работает на Linux или Unix.
Существует также некоторая поддержка записи хранимых процедур Oracle в Perl.
Поскольку Oracle имеет созданный в JVM, можно разработать сохраненный procs в Java, но также и в non-java-languages, которые используют JVM, которая означает языки как JACL, JYTHON, СХЕМА и Groovy. Посмотрите здесь: http://db360.blogspot.com/2006/08/oracle-database-programming-using-java_01.html и http://en.wikipedia.org/wiki/List_of_JVM_languages.
DB2 для Z/OS является базой данных, которые поддерживают большинство языков, как я знаю. Это поддерживает КОБОЛ, C/C++, JAVA как процедура хранилища, Это, конечно, также поддерживает процедуру SQL.