Языки, отличные от SQL в postgres

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

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

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

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

Итак, это напыщенная речь по первой части вопроса. Хотя задушевно.

is there any valid reason to use an untrusted language? It seems like making it so that any user can execute any operation would be a bad idea

Боже мой, да, это так! Этакая «атака внедрения Perl»? Я подумал, что это почти стоит того, чтобы посмотреть, что происходит.

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

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

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

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

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

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

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

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

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

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

С моей точки зрения, я полагаю, что ответ - это зависит от обстоятельств.

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

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

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

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

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

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

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

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