servitRM Feb 19 2013 at 09:54

Примеры генерации и отправки Email средствами СУБД Caché

6 min

4.3K

InterSystems corporate blogProgramming*

Tutorial

Comments 44

lair Feb 19 2013 at 12:12

Всё это можно реализовать непосредственно в самой СУБД Caché,

А зачем? принцип разделения ответственностей не?

servitRM Feb 19 2013 at 12:46

Всё верно.
Но никто не мешает построить на Caché grid из серверов и дать им свои роли и соответственно зоны ответственности: БД, сервера приложений, сервера отчётов, BI, Web Front-End и т.д.

Если кто-то из нехороших людей безответственно залезет в БД, минуя «ответственное звено», и нагадит, администратор всегда может об этом узнать, в том числе по SMS.
Отправка уведомления на триггерах для чувствительных данных в данном случае оправдано.

DAiMor Feb 19 2013 at 12:50

Это больше особенности самой СУБД Caché как таковой. Реализация приложения делается в самой БД, и таким образом из стороннего будет только Веб-сервер да статика.

lair Feb 19 2013 at 12:51

Ergo, это не СУБД.

DAiMor Feb 19 2013 at 13:05

Что такое Ergo?

lair Feb 19 2013 at 13:07

«Следовательно».

DAiMor Feb 19 2013 at 13:21

В латыни не силен.
Не вижу оснований, в том что Caché не может быть СУБД.
далеко ходить не надо на wiki

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

И в Caché, все это есть, кстати там же на wiki в качестве примера СУБД есть и Caché

lair Feb 19 2013 at 14:25

Может быть. Но применять ее предлагается не как СУБД.

DAiMor Feb 19 2013 at 14:46

На Oracle можно сделать то же самое, и она при этом остается СУБД.
Данный пост просто пример, того как реализовать задачу отправки email из приложения на Caché

lair Feb 19 2013 at 14:51

И на MS SQL можно. Но не нужно. Имено потому, что СУБД, а не сервер приложений.

DAiMor Feb 19 2013 at 14:53

а в Caché можно потому что это не только СУБД но и сервер приложений, и поверьте оно от этого ничего не теряет.

lair Feb 19 2013 at 14:56

Ходим по кругу.

Реализовывать отправку сообщений в СУБД можно, но не нужно. Реализовывать отправку сообщений в сервере приложений — можно.

Всё. Куда вы Cache положите, тот вариант и верен.

servitRM Feb 19 2013 at 15:43

Куда вы Cache положите, тот вариант и верен.

От этого СУБД Caché не перестанет именоваться СУБД и относиться к категории СУБД.

В статье, по-моему, всё предельно чётко обозначено:

Всё это можно реализовать непосредственно в самой СУБД Caché, выступающей здесь и как ~~почтовый~~ сервер приложений.

lair Feb 19 2013 at 15:45

От этого СУБД Caché не перестанет именоваться СУБД и относиться к категории СУБД

См. выше. Если она СУБД, не надо в ней реализовывать бизнес-логику и решения уровня приложения.

DAiMor Feb 19 2013 at 15:47

См. выше. Если она СУБД, не надо в ней реализовывать бизнес-логику и решения уровня приложения.

Почему?

lair Feb 19 2013 at 15:50

Потому что она СУБД. Опыт запихивания логики в СУБД показывает, что СУБД от этого плохеет.

«Не предназначены кролики для лазанья».

SRP — великая вещь.

DAiMor Feb 19 2013 at 15:54

И при этом это не мешает работе тысяч проектов на Caché, в которых и данные и бизнес-логика в одном месте.

lair Feb 19 2013 at 15:55

Потому что Cache — не чистая СУБД.

servitRM Feb 19 2013 at 17:06

Потому что она СУБД. Опыт запихивания логики в СУБД показывает, что СУБД от этого плохеет.

Автор: Том Кайт
Название: «Oracle для профессионалов»
ISBN 5-93772-072-5 (рус.)
ISBN 1-861004-82-6 (англ.)

Приведу некоторые выдержки (стр. 38 раздел «Мой подход»):

Я предпочитаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в СУБД, я так и сделаю. Для этого есть две причины. Первая и главная состоит в том, что если встроить функциональность в СУБД, то её можно будет применять где угодно.
-//-
СУБД Oracle — это моя виртуальная машина, моя «виртуальная операционная система».
Мой подход состоит в том, чтобы делать в СУБД всё, что возможно. Если требования выходят за пределы возможностей СУБД, я реализую соответствующие функции на языке Java вне СУБД.
-//-
При разработке приложений баз данных я использую очень простую мантру:

если можно, сделай это с помощью одного оператора SQL;

если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;

если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;

если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке С;

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

Это относится и к СУБД Caché.

PS: надеюсь, опыт и доводы Тома Кайта для Вас будут более убедительны.

lair Feb 19 2013 at 17:10

Нет, не будут.

Я предпочитаю намного более взвешенный подход, описанный Фаулером: www.martinfowler.com/articles/dblogic.html

(и он согласуется с моим личным опытом о том, сколько стоит поддержка решения, сделанного в БД, по сравнению с решением, сделанным вне БД)

DAiMor Feb 19 2013 at 17:24

Есть опыт работы с приложениями на Cache?

lair Feb 19 2013 at 17:27

Нет. Я же сказал, Cache — не только СУБД, поэтому к ней это малоприменимо.

servitRM Feb 19 2013 at 17:48

Выгоден зоопарк технологий — используйте зоопарк.

morisson Feb 19 2013 at 15:48

Почему не нужно? Caché и СУБД и сервер приложений одновременно.

lair Feb 19 2013 at 15:50

Если она сервер приложений — можете реализовывать в ней прикладную логику сколько угодно.

morisson Feb 19 2013 at 18:18

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

servitRM Feb 19 2013 at 13:10

Эрго

servitRM Feb 19 2013 at 13:09

Нет, это всё-таки СУБД, но с дополнительными возможностями.
Вот Ensemble — это уже платформа.

LighteR Feb 19 2013 at 15:06

В пост врывается PostgreSQL с pl/python:

CREATE OR REPLACE FUNCTION sendmail()
  RETURNS void
AS $$
	import smtplib
	from email.mime.text import MIMEText

	email_from = 'sender@example.com'
	email_to = 'receiver@example.com'
	msg = MIMEText('')
	msg['Subject'] = 'Email sending from postgres'
	msg['From'] = email_from
	msg['To'] = email_to

	s = smtplib.SMTP('localhost')
	s.sendmail(email_from, [email_to], msg.as_string())
	s.quit()
$$ LANGUAGE plpythonu;

servitRM Feb 19 2013 at 15:36

В СУБД Caché тоже можно писать хранимые процедуры на «внешних» языках типа C/C++, .NET [C#/etc.], Java.
Только речь в статье шла о встроенных возможностях Caché и примеры были даны на одном из встроенных языков — COS.

LighteR Feb 19 2013 at 15:44

Мне не совсем понятно что вы подразумеваете под терминами «внешние языки» и «встроенные языки» в контексте написания хранимых процедур.

servitRM Feb 19 2013 at 16:40

Программа на COS исполняется в адресном пространстве Caché.
Внешняя программа — в отдельном адресном пространстве. Проще говоря, это будет отдельный процесс, внешний по отношению к Caché и следовательно к данным в ней.
Отсюда неизбежны потери на переключение контекста.

Есть ведь разница в скорости, если на Java в цикле выполнить некую работу здесь же или вынести в отдельную процедуру, и тем более если адресовать её внешнему исполнителю, например на Python.

LighteR Feb 20 2013 at 12:51

Я почему вы решили, что pl/python в postgresql выполняется в отдельном процессе?

servitRM Feb 20 2013 at 13:27

Я где-то упомянул pl/python или postgresql?
Речь шла сугубо о Caché.

PL/Python — Python Procedural Language

To install PL/Python in a particular database, use bla-bla-bla

COS в Caché инсталлировать не нужно, так же как и PL/pgSQL в PostgreSQL

In PostgreSQL 9.0 and later, PL/pgSQL is installed by default

LighteR Mar 5 2013 at 23:27

Просто вы сделали акцент на слове «встроенный» как бы указывая на то, что это некоторое преимущество перед тем примером, что я привел. После моего вопроса о том что есть «встроенность» вы привели единственный критерий в виде выполнения в том же процессе, и на мой вопрос о том, с чего вы взяли, что pl/python выполняется в другом процессе вы как-то ловко попытались уйти от ответа.

COS в Caché инсталлировать не нужно, так же как и PL/pgSQL в PostgreSQL
| In PostgreSQL 9.0 and later, PL/pgSQL is installed by default

Мне не совсем понятно что вы хотели этим сказать. Собственно до версии 9.0 практически ту же операции нужно было проделывать и с pl/pgsql, но это еще не говорит о том, что pl/pgsql не был встроенным языком в версиях <9.0, ибо это не совсем инсталяция, а скорее активация поддержки pl/pgsql в конкретной базе.

servitRM Mar 6 2013 at 12:33

Когда я вижу в документации:

To install PL/Python in a particular database <...>
As of PostgreSQL 7.4, PL/Python is only available as an «untrusted» language <...>

у меня почему-то возникают сомнения. А, вот, с PL/pgSQL сомнений нет никаких.
Ну да ладно, другие языки для PostgreSQL оставим в покое.

Для Oracle встроенным процедурным языком, расширяющим SQL, является PL/SQL, для MSSQL — T-SQL, для Caché — Caché ObjectScript, Caché Basic и Caché MultiValue Basic, для PostgreSQL — PL/pgSQL.

Примеры отправки письма на

PL/SQL
T-SQL

Можно, чтобы в пост «ворвался» ваш пример выше, но на PL/pgSQL?

lair Mar 6 2013 at 12:36

Вообще-то, для отправки письма из MS SQL использование T-SQL не нужно.

servitRM Mar 6 2013 at 12:47

Простейшего, как в примере выше, конечно, но более сложного — вряд ли.

LighteR Mar 13 2013 at 00:48

Можно, чтобы в пост «ворвался» ваш пример выше, но на PL/pgSQL?

Вас похоже задело за живое сравнение с postgre. pl/pgsql вообще-то не предназначен для подобных вещей, так что странно просить привести пример на нем.

servitRM Mar 13 2013 at 10:08

pl/pgsql вообще-то не предназначен для подобных вещей

Спасибо, я получил ответ на свой вопрос.

morisson Feb 19 2013 at 18:09

С отправкой писем понятно. А как насчет обработки входящих писем внутри Caché?

doublefint Feb 19 2013 at 19:30

Или что насчет отправки через «какой-нибудь» gmail.com :)

servitRM Feb 19 2013 at 19:56

Если знаете IP/DNS, порт, логин/пароль учётки на SMTP-сервере и у Caché есть на него доступ — нет проблем.
Но я бы всё-таки пользовался внутренним корпоративным почтовым сервером, который уже отправит куда надо.

servitRM Feb 19 2013 at 19:33

По ссылке в статье есть описание класса %Net.POP3 с примерами: Fetching Email from a POP3 Server