Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 44

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

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

Если кто-то из нехороших людей безответственно залезет в БД, минуя «ответственное звено», и нагадит, администратор всегда может об этом узнать, в том числе по SMS.
Отправка уведомления на триггерах для чувствительных данных в данном случае оправдано.
Рейтинг скрыт
Это больше особенности самой СУБД Caché как таковой. Реализация приложения делается в самой БД, и таким образом из стороннего будет только Веб-сервер да статика.
Рейтинг скрыт
Ergo, это не СУБД.
Рейтинг скрыт
Что такое Ergo?
Рейтинг скрыт
«Следовательно».
Рейтинг скрыт
В латыни не силен.
Не вижу оснований, в том что Caché не может быть СУБД.
далеко ходить не надо на wiki
совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных
И в Caché, все это есть, кстати там же на wiki в качестве примера СУБД есть и Caché
Рейтинг скрыт
Может быть. Но применять ее предлагается не как СУБД.
Рейтинг скрыт
На Oracle можно сделать то же самое, и она при этом остается СУБД.
Данный пост просто пример, того как реализовать задачу отправки email из приложения на Caché
Рейтинг скрыт
И на MS SQL можно. Но не нужно. Имено потому, что СУБД, а не сервер приложений.
Рейтинг скрыт
а в Caché можно потому что это не только СУБД но и сервер приложений, и поверьте оно от этого ничего не теряет.
Рейтинг скрыт
Ходим по кругу.

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

Всё. Куда вы Cache положите, тот вариант и верен.
Рейтинг скрыт
Куда вы Cache положите, тот вариант и верен.
От этого СУБД Caché не перестанет именоваться СУБД и относиться к категории СУБД.

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

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

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

SRP — великая вещь.
Рейтинг скрыт
И при этом это не мешает работе тысяч проектов на Caché, в которых и данные и бизнес-логика в одном месте.
Рейтинг скрыт
Потому что Cache — не чистая СУБД.
Рейтинг скрыт
Потому что она СУБД. Опыт запихивания логики в СУБД показывает, что СУБД от этого плохеет.

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

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

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

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

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

(и он согласуется с моим личным опытом о том, сколько стоит поддержка решения, сделанного в БД, по сравнению с решением, сделанным вне БД)
Рейтинг скрыт
Есть опыт работы с приложениями на Cache?
Рейтинг скрыт
Нет. Я же сказал, Cache — не только СУБД, поэтому к ней это малоприменимо.
Рейтинг скрыт
Выгоден зоопарк технологий — используйте зоопарк.
Рейтинг скрыт
Почему не нужно? Caché и СУБД и сервер приложений одновременно.
Рейтинг скрыт
Если она сервер приложений — можете реализовывать в ней прикладную логику сколько угодно.
Рейтинг скрыт
В том и «фишка», что купив Caché получаешь СУБД и сервер приложений, в результате выстроить масштабированное решение на основе ECP.
Рейтинг скрыт
В пост врывается 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;
Рейтинг скрыт
В СУБД Caché тоже можно писать хранимые процедуры на «внешних» языках типа C/C++, .NET [C#/etc.], Java.
Только речь в статье шла о встроенных возможностях Caché и примеры были даны на одном из встроенных языков — COS.
Рейтинг скрыт
Мне не совсем понятно что вы подразумеваете под терминами «внешние языки» и «встроенные языки» в контексте написания хранимых процедур.
Рейтинг скрыт
Программа на COS исполняется в адресном пространстве Caché.
Внешняя программа — в отдельном адресном пространстве. Проще говоря, это будет отдельный процесс, внешний по отношению к Caché и следовательно к данным в ней.
Отсюда неизбежны потери на переключение контекста.

Есть ведь разница в скорости, если на Java в цикле выполнить некую работу здесь же или вынести в отдельную процедуру, и тем более если адресовать её внешнему исполнителю, например на Python.
Рейтинг скрыт
Я почему вы решили, что pl/python в postgresql выполняется в отдельном процессе?
Рейтинг скрыт
Я где-то упомянул 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
Рейтинг скрыт
Просто вы сделали акцент на слове «встроенный» как бы указывая на то, что это некоторое преимущество перед тем примером, что я привел. После моего вопроса о том что есть «встроенность» вы привели единственный критерий в виде выполнения в том же процессе, и на мой вопрос о том, с чего вы взяли, что 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 в конкретной базе.
Рейтинг скрыт
Когда я вижу в документации:

  • 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/pgSQL?
Рейтинг скрыт
Вообще-то, для отправки письма из MS SQL использование T-SQL не нужно.
Рейтинг скрыт
Простейшего, как в примере выше, конечно, но более сложного — вряд ли.
Рейтинг скрыт
Можно, чтобы в пост «ворвался» ваш пример выше, но на PL/pgSQL?

Вас похоже задело за живое сравнение с postgre. pl/pgsql вообще-то не предназначен для подобных вещей, так что странно просить привести пример на нем.
Рейтинг скрыт
pl/pgsql вообще-то не предназначен для подобных вещей
Спасибо, я получил ответ на свой вопрос.
Рейтинг скрыт
С отправкой писем понятно. А как насчет обработки входящих писем внутри Caché?
Рейтинг скрыт
Или что насчет отправки через «какой-нибудь» gmail.com :)
Рейтинг скрыт
Если знаете IP/DNS, порт, логин/пароль учётки на SMTP-сервере и у Caché есть на него доступ — нет проблем.
Но я бы всё-таки пользовался внутренним корпоративным почтовым сервером, который уже отправит куда надо.
Рейтинг скрыт
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr