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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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