Мне смутно помнится, что когда Дуров первый раз хотел запустить свою валюту TON, то в США были сильно и продуктивно недовольны, и Дуров от TON отказался.
И вот, вроде бы недавно этот TON таки запустили в работу. Возможно с этим и связаны претензии - валюты-конкуренты никому не нужны.
Они ездят не по асфальту, а по специальной грунтовке для танков и прочей техники. Асфальтовую дорогу пересекают один раз, и в этом месте дорогу забетонировали. Так что "своим ходом" - это не совсем так, просто у них обучение начинается не на самом полигоне а прям от училища, и дорога как-бы входит в полигон.
"Наконец кто-то заметил" - это про современный дизайн интерфейсов. Загадаем квест и посмотрим столько людей догадаются потыкать в неописанные в меню и справке клавиши.
Желание ускорить обработку логики путем переписывания с PL/SQL на иной язык, в 99% приведет к замедлению, или значительному замедлению, за счет лишних преобразований данных. Язык PL/SQL расчитан на максимально эффективную работу с данными. На том же Firebird, процедуры/функции на PL/SQL не интерпретируются при каждом вызове, работает предварительно скомпилированный байт-код.
Из личной практики - перенос обработки данных из клиентского приложения в процедуру на PL/SQL на сервере в ряде случаев дает ускорение на порядки, даже в случае если клиент запущен на том же компе что и сервер. Соответственно, аналогичные результаты могут быть получены и при трехзвенке, если только у вас там БД не используется как склад, а вся работа с данными построена на каком-нибудь ORM вне базы.
UDR/UDF имеет смысл применять когда требуется функционал который отсутствует в PL/SQL, к примеру какая-нибудь сложная математика. В том же Firebird, во времена FB2.0 или даже раньше, UDF была актуальна для написания функций которых в PL/SQL не было. В более новых версиях FB значительно увеличили количество встроенных функций, и потребность в UDF практически сошла на нет. Механизм UDR значительно расширен по сравнению с UDF, но судя по общению в программистами на FB, практически не восстребован.
В Firebird 3.0 была введена плагинная архитектура для расширения возможностей Firebird. Одним из таких плагинов является External Engine (внешние движки). Механизм UDR (User Defined Routines — определяемые пользователем подпрограммы) добавляет слой поверх интерфейса движка FirebirdExternal.
UDR могут быть написаны на любом языке программирования (необязательно компилируемые в объектные коды), для этого необходим соответствующий External Engine плагин. Например, существуют плагины для написания внешних модулей на Java или на любом из .NET языков.
Тем не менее, обычно рассматриваются варианты написания UDR на Delphi/FreePascal и на c++. По другим языкам инструкций не встречал, впрочем и не искал.
Для реализации бизнес-логики лично мне вполне хватает возможностей PL/SQL, что бы тянуть в проект UDF/UDR нужны ОООЧЕНЬ веские причины. Ибо все это становится платформо- и ос- зависимым, в то время как PL/SQL работает на любой версии сервера (точнее, под нужной версией сервера на любой поддерживаемой сервером платформе).
Интересная статья как пример практической обработки и анализа данных. Но, IMHO, все портит натягивание повесточки о глобальном потеплении на любые цифры. В статье анализируется данные по России, за 50 лет, а выводы делаются про всю планету в масштабе десятков тысяч лет. Единственное что видно - меняется климат в конкретной местности, что бы делать вывод про планету, нужно как минимум анализировать данные по всей поверхности, а не по кусочкам, ибо где-то потеплело, а где-то похолодало. Ну и вывод что в потеплении виновата деятельность человека - тоже непонятно откуда берется. Ибо даже в наблюдаемом периоде были десятилетия нехарактерного для "антропогенного глобального потепления" замедления роста температуры. Предполагается некая модель климата и ведется наблюдение, насколько фактические данные совпадает с моделью. Регулярно возникают нескладухи и им ищут объяснение. И потом это объяснение должно быть подтверждено. Сейчас возрастание температуры - очередная нескладуха, под которую подгоняют теории, и некоторые люди на этой повесточке умудряются нехило подзаработать.
Хотел бы обратить внимание что сия проблема в этом виде рождается и таким способом решается (замена varchar на char) исключительно в блокировочниках. В версионниках новая версия записи никогда не пишется на старое место, всегда на новое, и озвученная проблема либо не возникнет, либо возникнет, но таким методом не решится.
Это камент, на случай если кто-то попытается сделать вывод что "varchar это плохо". Это плохо только на конкретном сервере, на конкретном движке, в определенного типа приложениях.
Ну вот поэтому и написана эта статья - как поставить актуальную версию Firebird нее ожидая чуда от майнтайнеров. Статья написана разработчиком Firebird для разработчиков приложений на Firebird, которые используют сервер в полной мере и знают что там есть нужного в новой версии.
Для тех кому пофиг какая версия - те ставят тот Firebird что есть в дистрибутиве линуха. Для "начать" - это пойдет. Но для "установить сервер для конретной программы которая протестирована с конкретной версией Firebird" - такое не прокатит. Версии различаются, и в ряде случаев - это критично.
Технический камент. Текст на алом фоне - это вырвиглаз, смотреть невозможно. Интуитивно хочется провести параллели между таким оформлением текста и тем софтом который разрабатывает фирма автора. Ничего личного.
Мне смутно помнится, что когда Дуров первый раз хотел запустить свою валюту TON, то в США были сильно и продуктивно недовольны, и Дуров от TON отказался.
И вот, вроде бы недавно этот TON таки запустили в работу. Возможно с этим и связаны претензии - валюты-конкуренты никому не нужны.
Они ездят не по асфальту, а по специальной грунтовке для танков и прочей техники. Асфальтовую дорогу пересекают один раз, и в этом месте дорогу забетонировали. Так что "своим ходом" - это не совсем так, просто у них обучение начинается не на самом полигоне а прям от училища, и дорога как-бы входит в полигон.
Тут какая-то другая команда должна была быть?
Firebird так умеет.
Неправильно (заглавная I). Правильно так:
Если записать тот же самый запрос по другому, то становится виднее "почему так".
SELECT SUM(o.amount)FROM operation oINNER JOIN operation_tag ot1 ON (ot1.operation_id = o.operation_id )INNER JOIN operation_tag ot2 ON (ot2.operation_id = o.operation_id )INNER JOIN operation_tag ot3 ON (ot3.operation_id = o.operation_id )INNER JOIN tags t1 ON (t1.tag_id = ot1.tag_id )INNER JOIN tags t2 ON (t2.tag_id = ot2.tag_id )INNER JOIN tags t3 ON (t3.tag_id = ot3.tag_id )WHERE (1=1) AND (o.created_at BETWEEN '2023-08-01' AND '2023-08-31')AND (t1.name = 'provider' ) AND (t1.value = 'someProvider' )
AND (t2.name = 'merchant' ) AND (t2.value = 'someMerchant' )
AND (t3.name = 'customer_id' ) AND (t3.value = 'someUniqueCustomerId')Мда... форматирование в каментах неудачное...
Открылась его копия, и не одна.
https://resql.ru
Тут даже регистрироваться можно, но активность нулевая, все в телеграм ушли.
Странно, как может не быть OUTER JOIN.
Сходил посмотреть доку - там пишут что есть OUTER, да я и сам писал запросы на MySQL с OUTER JOIN.
https://dev.mysql.com/doc/refman/8.0/en/join.html
А что, кто-то с таким лайком может использовать индексы??
"Наконец кто-то заметил" - это про современный дизайн интерфейсов. Загадаем квест и посмотрим столько людей догадаются потыкать в неописанные в меню и справке клавиши.
Желание ускорить обработку логики путем переписывания с PL/SQL на иной язык, в 99% приведет к замедлению, или значительному замедлению, за счет лишних преобразований данных. Язык PL/SQL расчитан на максимально эффективную работу с данными. На том же Firebird, процедуры/функции на PL/SQL не интерпретируются при каждом вызове, работает предварительно скомпилированный байт-код.
Из личной практики - перенос обработки данных из клиентского приложения в процедуру на PL/SQL на сервере в ряде случаев дает ускорение на порядки, даже в случае если клиент запущен на том же компе что и сервер. Соответственно, аналогичные результаты могут быть получены и при трехзвенке, если только у вас там БД не используется как склад, а вся работа с данными построена на каком-нибудь ORM вне базы.
UDR/UDF имеет смысл применять когда требуется функционал который отсутствует в PL/SQL, к примеру какая-нибудь сложная математика. В том же Firebird, во времена FB2.0 или даже раньше, UDF была актуальна для написания функций которых в PL/SQL не было. В более новых версиях FB значительно увеличили количество встроенных функций, и потребность в UDF практически сошла на нет. Механизм UDR значительно расширен по сравнению с UDF, но судя по общению в программистами на FB, практически не восстребован.
В Firebird 3.0 была введена плагинная архитектура для расширения возможностей Firebird. Одним из таких плагинов является External Engine (внешние движки). Механизм UDR (User Defined Routines — определяемые пользователем подпрограммы) добавляет слой поверх интерфейса движка FirebirdExternal.
UDR могут быть написаны на любом языке программирования (необязательно
компилируемые в объектные коды), для этого необходим соответствующий External
Engine плагин. Например, существуют плагины для написания внешних модулей на Java или на любом из .NET языков.
Тем не менее, обычно рассматриваются варианты написания UDR на Delphi/FreePascal и на c++. По другим языкам инструкций не встречал, впрочем и не искал.
Для реализации бизнес-логики лично мне вполне хватает возможностей PL/SQL, что бы тянуть в проект UDF/UDR нужны ОООЧЕНЬ веские причины. Ибо все это становится платформо- и ос- зависимым, в то время как PL/SQL работает на любой версии сервера (точнее, под нужной версией сервера на любой поддерживаемой сервером платформе).
Вы неправильно полагаете.
Штатные утилиты
pg_dumpиpg_basebackupне требуют остановки работы сервера, не мешают работе клиентов, не блокируют данные. И так было всегда.И это не исчерпывающий список вариантов сделать бэкап базы на PostgreSQL.
Интересная статья как пример практической обработки и анализа данных. Но, IMHO, все портит натягивание повесточки о глобальном потеплении на любые цифры. В статье анализируется данные по России, за 50 лет, а выводы делаются про всю планету в масштабе десятков тысяч лет. Единственное что видно - меняется климат в конкретной местности, что бы делать вывод про планету, нужно как минимум анализировать данные по всей поверхности, а не по кусочкам, ибо где-то потеплело, а где-то похолодало. Ну и вывод что в потеплении виновата деятельность человека - тоже непонятно откуда берется. Ибо даже в наблюдаемом периоде были десятилетия нехарактерного для "антропогенного глобального потепления" замедления роста температуры. Предполагается некая модель климата и ведется наблюдение, насколько фактические данные совпадает с моделью. Регулярно возникают нескладухи и им ищут объяснение. И потом это объяснение должно быть подтверждено. Сейчас возрастание температуры - очередная нескладуха, под которую подгоняют теории, и некоторые люди на этой повесточке умудряются нехило подзаработать.
Почему-то в списке отсутствует Firebird/RedDatabase, в свете импортозамещения - это вполне актуальное решение.
Хотел бы обратить внимание что сия проблема в этом виде рождается и таким способом решается (замена varchar на char) исключительно в блокировочниках. В версионниках новая версия записи никогда не пишется на старое место, всегда на новое, и озвученная проблема либо не возникнет, либо возникнет, но таким методом не решится.
Это камент, на случай если кто-то попытается сделать вывод что "varchar это плохо". Это плохо только на конкретном сервере, на конкретном движке, в определенного типа приложениях.
В Linux это называется Zenity
https://help.gnome.org/users/zenity/stable/
https://ru.wikipedia.org/wiki/Zenity
А чем штатный
journalctlне угодил?Ну вот поэтому и написана эта статья - как поставить актуальную версию Firebird нее ожидая чуда от майнтайнеров. Статья написана разработчиком Firebird для разработчиков приложений на Firebird, которые используют сервер в полной мере и знают что там есть нужного в новой версии.
Для тех кому пофиг какая версия - те ставят тот Firebird что есть в дистрибутиве линуха. Для "начать" - это пойдет. Но для "установить сервер для конретной программы которая протестирована с конкретной версией Firebird" - такое не прокатит. Версии различаются, и в ряде случаев - это критично.
Технический камент. Текст на алом фоне - это вырвиглаз, смотреть невозможно. Интуитивно хочется провести параллели между таким оформлением текста и тем софтом который разрабатывает фирма автора. Ничего личного.