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

StackOverflow https://stackoverflow.com/questions/39517

Вопрос

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

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

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

ПС.Бонусные баллы, если кто-то сможет сделать ПЛ/ЛОЛКОД кажутся полезными.

Это было полезно?

Решение

«Разве это [манипулирование текстом] не является чем-то вроде того, что следует запрограммировать в приложении?»

Обычно да.Общепринятое»трехъярусный«Проектирование приложений для баз данных предполагает, что ваша логика должна находиться на среднем уровне, между клиентом и базой данных.Однако иногда вам нужна некоторая логика в триггере или индексация функции, что требует помещения некоторого кода в базу данных.<i>In that case all the usual "which language should I use?"</i> <b>В этом случае все обычное «какой язык мне следует использовать?»</b> <i>questions come up.</i> <b>возникают вопросы.</b>

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

Боже мой, да, так и есть!Что-то вроде «Атаки с помощью Perl-инъекций»?«Почти стоит это сделать, просто чтобы посмотреть, что произойдет», — подумал я.

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top