Языки кроме SQL в postgres

Question

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

Например, в документации сказано, что основное использование PL / Perl в том, что он довольно хорош в манипулировании текстом. Но разве это не то, что должно быть запрограммировано в приложении?

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

PS. Бонусные баллы, если кто-то может заставить PL / LOLCODE показаться полезным.

Answer 1

@ Майк: такое мышление заставляет меня нервничать. Я много раз слышал, что «это должно быть бесконечно переносимо», но когда задают вопрос: действительно ли вы предвидите, что будет какое-либо портирование? ответ: нет.

Придерживаясь наименьшего общего знаменателя, можно реально снизить производительность, как и введение уровней абстракции (ORM, PHP PDO и т. Д.). Мое мнение таково:

• Оцените реалистично, если есть необходимость поддержки нескольких РСУБД. Например, если вы пишете веб-приложение с открытым исходным кодом, есть вероятность, что вам нужно как минимум поддерживать MySQL и PostgreSQL (если не MSSQL и Oracle)
• После оценки максимально используйте платформу, которую вы определили

И кстати: вы смешиваете реляционные базы данных с нереляционными базами данных (CouchDB - это , а не СУБД, сравнимая, например, с Oracle), еще раз иллюстрируя то, что предполагаемая потребность в переносимости во много раз сильно переоценивается.

Answer 2

"Разве это не [манипулирование текстом] больше того, что должно быть запрограммировано в приложении?"

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

Если вам нужна лишь небольшая логика, вероятно, следует использовать наиболее переносимый язык (pl / pgSQL). Если вам нужно заняться серьезным программированием, вам лучше использовать более выразительный язык (возможно, pl / ruby). Это всегда будет призыв к суду.

"есть ли веская причина для использования ненадежного языка?"

Как и выше, да. Опять же, лучше всего использовать прямой доступ к файлам (например) на вашем среднем уровне, когда это возможно, но если вам нужно отключить работу на основе триггеров (для которых может потребоваться доступ к данным, недоступным непосредственно для вашего среднего уровня), то вам не нужно доверять языки. Это не идеально, и его вообще следует избегать. И вам определенно нужно охранять доступ к нему.

Answer 3

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

Answer 4

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

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

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

Затем я написал алгоритм биннинга в PL / pgSQL, и он работал намного быстрее.

Что касается ненадежных языков, я услышал подкаст от Джоша Беркуса (адвоката postgres), который обсуждал применение postgresql, которое вводило данные из MySQL как часть его обработки, так что само сообщение обрабатывалось сервером postgres. Я не помню всех подробностей, я думаю, что это был подкаст FLOSS Weekly , который является довольно интересным обсуждением истории PostGRESQL и некоторых проблем, с которыми он сталкивается.

Answer 5

В наши дни любая «уникальная» или «классная» функция в СУБД вызывает у меня невероятную нервозность. У меня появляется сыпь, и я должен прекратить работу, пока зуд не исчезнет.

Я просто ненавижу быть без необходимости привязанным к платформе. Предположим, вы собрали большую часть вашей системы в PL / Perl внутри базы данных. Или в C # в SQL Server, или в PL / SQL в Oracle, существует множество примеров *.

Теперь вы внезапно обнаруживаете, что выбранная вами платформа не масштабируется. Или не достаточно быстро. Или что-то. Хуже того, в блоке базы данных появился новый ребенок (что-то вроде MonetDB, CouchDB, Cache, скажем, намного круче), который решит все ваши проблемы (даже если ваша единственная проблема, как у меня, - это неохлаждаемая платформа базы данных). И вы не можете переключиться на него, не перекодировав половину своего приложения.

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

Итак, это напыщенная речь по первой части вопроса. Сердечный, хотя.

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

Боже мой, да, это так! Этакая «атака с помощью Perl»? Почти стоило бы сделать это, просто чтобы посмотреть, что произойдет, я бы подумал.

По философским причинам, изложенным выше, я думаю, что передам вызов PL / LOLCODE. Хотя я был несколько удивлен, обнаружив, что это была ссылка на что-то существующее.

Answer 6

Примером полезной хранимой процедуры, которую я недавно написал на внешнем языке, которая была бы невозможна в pl / sql, является версия 'df', которая позволяла генераторам таблиц SQL выбирать табличное пространство с наибольшим количеством свободного места, доступным в во время выполнения.

Я использовал plperlu, и это было относительно просто, хотя я должен был быть осторожен с набором данных.

Answer 7

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