Если знаете IP/DNS, порт, логин/пароль учётки на SMTP-сервере и у Caché есть на него доступ — нет проблем.
Но я бы всё-таки пользовался внутренним корпоративным почтовым сервером, который уже отправит куда надо.
Была статья на Хабре на похожую тему.
Помимо прочего там автором использовалась неполная и нечёткая предметная область, информация о которой дополняется в процессе использования системы (подобие EAV только для NoSQL).
Ссылка на реальный проект, указанная автором статьи немного устарела, здесь более новая (внизу страницы есть логотип Caché).
Кстати, с версии Caché 2012.2 можно BI использовать и над неструктурированными данными.
Я не слышал, чтобы какие-то современные NoSQL-системы имели встроенную поддержку SQL, не говоря уже о MDX над живыми данными.
Потому что она СУБД. Опыт запихивания логики в СУБД показывает, что СУБД от этого плохеет.
Автор: Том Кайт
Название: «Oracle для профессионалов»
ISBN 5-93772-072-5 (рус.)
ISBN 1-861004-82-6 (англ.)
Приведу некоторые выдержки (стр. 38 раздел «Мой подход»):
Я предпочитаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в СУБД, я так и сделаю. Для этого есть две причины. Первая и главная состоит в том, что если встроить функциональность в СУБД, то её можно будет применять где угодно.
-//-
СУБД Oracle — это моя виртуальная машина, моя «виртуальная операционная система».
Мой подход состоит в том, чтобы делать в СУБД всё, что возможно. Если требования выходят за пределы возможностей СУБД, я реализую соответствующие функции на языке Java вне СУБД.
-//-
При разработке приложений баз данных я использую очень простую мантру:
если можно, сделай это с помощью одного оператора SQL;
если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке С;
если это нельзя реализовать в виде внешней процедуры на языке С, надо серьёзно подумать, зачем это вообще делать...
Это относится и к СУБД Caché.
PS: надеюсь, опыт и доводы Тома Кайта для Вас будут более убедительны.
Программа на COS исполняется в адресном пространстве Caché.
Внешняя программа — в отдельном адресном пространстве. Проще говоря, это будет отдельный процесс, внешний по отношению к Caché и следовательно к данным в ней.
Отсюда неизбежны потери на переключение контекста.
Есть ведь разница в скорости, если на Java в цикле выполнить некую работу здесь же или вынести в отдельную процедуру, и тем более если адресовать её внешнему исполнителю, например на Python.
В СУБД Caché тоже можно писать хранимые процедуры на «внешних» языках типа C/C++, .NET [C#/etc.], Java.
Только речь в статье шла о встроенных возможностях Caché и примеры были даны на одном из встроенных языков — COS.
Всё верно.
Но никто не мешает построить на Caché grid из серверов и дать им свои роли и соответственно зоны ответственности: БД, сервера приложений, сервера отчётов, BI, Web Front-End и т.д.
Если кто-то из нехороших людей безответственно залезет в БД, минуя «ответственное звено», и нагадит, администратор всегда может об этом узнать, в том числе по SMS.
Отправка уведомления на триггерах для чувствительных данных в данном случае оправдано.
В 2013 году Mars One начинает поиск и отбор лучших кандидатов, что станут участниками первой миссии на Марс в 2023 году.
2023 — только взлёт или уже посадка?
Возрастной диапазон ограничен. Хотя верхние границы еще точно не определены, нижний возрастной предел 18 лет. К моменту приземления этому человеку уже будет 28
Из статьи это неочевидно.
Судя по ролику, отлёт — сентябрь 2022, прилёт — апрель 2023, время в пути — 7 месяцев.
7 месяцев — это уже гуманнее.
А я пользуюсь СУБД Caché, которая одновременно предоставляет и объектный, и реляционный, и прямой доступ.
Встроенная поддержка взаимного отображения, например классов в таблицы и таблиц в классы, позволяет в SQL использовать объектные расширения из любого ODBC/JDBC клиента.
Подробности можно почитать в документации.
Конечно.
Но при BULK insert никто с этими данными и не должен работать.
Если к примеру вам нужно залить 5Тб данных из каких-нибудь журналов для нужд BI, то эффективнее будет отключить построение индексов, залить данные, а потом запустить параллельную индексацию с построением кубов.
Это будет быстрее, чем одновременно делать сразу всё.
Ещё есть вариант построения индексов асинхронно процессу записи собственно данных.
PS: а как вам вариант построения сначала индексов, а заливки данных потом?
Такое тоже возможно, когда СУБД предоставляет прямой доступ (NoSQL), как внутри, так и снаружи, — наряду с традиционным реляционным.
Но я бы всё-таки пользовался внутренним корпоративным почтовым сервером, который уже отправит куда надо.
Была статья на Хабре на похожую тему.
Помимо прочего там автором использовалась неполная и нечёткая предметная область, информация о которой дополняется в процессе использования системы (подобие EAV только для NoSQL).
Ссылка на реальный проект, указанная автором статьи немного устарела, здесь более новая (внизу страницы есть логотип Caché).
Кстати, с версии Caché 2012.2 можно BI использовать и над неструктурированными данными.
Я не слышал, чтобы какие-то современные NoSQL-системы имели встроенную поддержку SQL, не говоря уже о MDX над живыми данными.
Автор: Том Кайт
Название: «Oracle для профессионалов»
ISBN 5-93772-072-5 (рус.)
ISBN 1-861004-82-6 (англ.)
Приведу некоторые выдержки (стр. 38 раздел «Мой подход»):
Это относится и к СУБД Caché.
PS: надеюсь, опыт и доводы Тома Кайта для Вас будут более убедительны.
Внешняя программа — в отдельном адресном пространстве. Проще говоря, это будет отдельный процесс, внешний по отношению к Caché и следовательно к данным в ней.
Отсюда неизбежны потери на переключение контекста.
Есть ведь разница в скорости, если на Java в цикле выполнить некую работу здесь же или вынести в отдельную процедуру, и тем более если адресовать её внешнему исполнителю, например на Python.
Дореляционные СУБД (60/70-е гг.) тоже на месте не стоя́т.
В статье, по-моему, всё предельно чётко обозначено:
Только речь в статье шла о встроенных возможностях Caché и примеры были даны на одном из встроенных языков — COS.
Вот Ensemble — это уже платформа.
Но никто не мешает построить на Caché grid из серверов и дать им свои роли и соответственно зоны ответственности: БД, сервера приложений, сервера отчётов, BI, Web Front-End и т.д.
Если кто-то из нехороших людей безответственно залезет в БД, минуя «ответственное звено», и нагадит, администратор всегда может об этом узнать, в том числе по SMS.
Отправка уведомления на триггерах для чувствительных данных в данном случае оправдано.
Из статьи это неочевидно.
Судя по ролику, отлёт — сентябрь 2022, прилёт — апрель 2023, время в пути — 7 месяцев.
7 месяцев — это уже гуманнее.
строгого или общего режима будут каюты?), чтобы уже никогда не вернуться.Хм. Заманчиво.
Похоже на смертную казнь с затягиванием исполнения.
Встроенная поддержка взаимного отображения, например классов в таблицы и таблиц в классы, позволяет в SQL использовать объектные расширения из любого ODBC/JDBC клиента.
Подробности можно почитать в документации.
при недвусмысленном
Но при BULK insert никто с этими данными и не должен работать.
Если к примеру вам нужно залить 5Тб данных из каких-нибудь журналов для нужд BI, то эффективнее будет отключить построение индексов, залить данные, а потом запустить параллельную индексацию с построением кубов.
Это будет быстрее, чем одновременно делать сразу всё.
Ещё есть вариант построения индексов асинхронно процессу записи собственно данных.
PS: а как вам вариант построения сначала индексов, а заливки данных потом?
Такое тоже возможно, когда СУБД предоставляет прямой доступ (NoSQL), как внутри, так и снаружи, — наряду с традиционным реляционным.