The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз СУБД PostgreSQL 15, opennews (??), 13-Окт-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


10. "Релиз СУБД PostgreSQL 15"  –4 +/
Сообщение от V100 (?), 13-Окт-22, 18:47 
Как минимум нет пакетов, невозможно объединять код встроенных процедур.  
Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз СУБД PostgreSQL 15"  +1 +/
Сообщение от Аноним (8), 13-Окт-22, 18:54 
Пакеты я на гуглил как sql packages и мне выдало ссылку на оракл. А второе для чего надо и как гуглится?
Ответить | Правка | Наверх | Cообщить модератору

18. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Твайлайт Спаркл (ok), 13-Окт-22, 19:06 
"plpgsql package"

https://www.postgresql.org/docs/current/plpgsql-porting.html
https://stackoverflow.com/questions/35043957/whats-the-equiv...

Ответить | Правка | Наверх | Cообщить модератору

23. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от v100 (?), 13-Окт-22, 19:19 
Использовать схемы вместо пакетов это не решение, а какой-то треш. Как работать с 20-50 схемами одновременно, непонятно.
Ответить | Правка | Наверх | Cообщить модератору

205. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от . (?), 17-Окт-22, 12:14 
В Oracle для каждого пользователя своя схема, никто не жалуется.
Ответить | Правка | Наверх | Cообщить модератору

214. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Anonimous (?), 19-Окт-22, 06:02 
В Oracle пакеты есть. И вот поэтому никто не жалуется.
Ответить | Правка | Наверх | Cообщить модератору

22. "Релиз СУБД PostgreSQL 15"  +4 +/
Сообщение от Аноним (22), 13-Окт-22, 19:18 
Да, да, бизнес-логика на процедурах в БД, этот изврат должен подохнуть вместе с ораклом.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

24. "Релиз СУБД PostgreSQL 15"  –7 +/
Сообщение от v100 (?), 13-Окт-22, 19:20 
к сожалению, пока нет альтенатив oracle. Логике на процедурах БД тоже нет альтернатив, как ни жаль
Ответить | Правка | Наверх | Cообщить модератору

84. "Релиз СУБД PostgreSQL 15"  +1 +/
Сообщение от Аноним (84), 14-Окт-22, 02:45 
Вы только на собеседовании этапе системного дизайна это не брякните. Тащить в плохо масштабирующийся shared ресурс бизнес-логику, еще и триггерами это промазывать - отличный способ получить "бутылочное горлышко" и запороть эффективное горизонтальное масштабирование.
Ответить | Правка | Наверх | Cообщить модератору

168. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Заноним (?), 15-Окт-22, 03:29 
Прикинь, окромя бизнес-логики, функции на СУБД могут и для других целей применяться.
Ответить | Правка | Наверх | Cообщить модератору

176. "Релиз СУБД PostgreSQL 15"  +2 +/
Сообщение от Прохожий (??), 15-Окт-22, 14:25 
Вы сами-то на собеседовании не брякните, что целостность данных будете на стороне сервера приложений обеспечивать. Я бы такого "архитектора" тут же пинками под зад проводил.
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

34. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Аноним (8), 13-Окт-22, 19:49 
А где ещё бизнес-логику писать? - в приложении что ли? (я опять просто хочу разобраться)
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

58. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от eugener (ok), 13-Окт-22, 21:08 
На сервере приложений. Классическая трёхзвенка.
Ответить | Правка | Наверх | Cообщить модератору

180. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Прохожий (??), 15-Окт-22, 15:01 
Не всегда она применима и уместна. Не бывает универсальных архитектур. Двузвенка, на всякий случай, не менее "классична", чем трёхзвенка. Так, к слову.
Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от VoDA (ok), 14-Окт-22, 09:32 
Да, бизнес-логику в приложении. Приложение или self-running docker или на сервере приложений в зависимости от технологии.
Заодно получите и легкость unit-тестирования и легкость обновления окружений. Заодно и асинхронное взаимодействие между отдельными приложениями.

У система на хранимках есть заметные недостатки:
* работа на хранимках в БД заточена под массовую обработку. И программисты думают так же. Изменения намного дороже и сложнее.
* код тестовых стендов с хранимками через пару-тройку месяцев разработки расходятся с продакшеном.
* очень мало людей могут мыслить массовой обработкой и эффективно писать системы. потому с системой на хранимках попадаешь в зависимость от конкретного человека. найти замену на рынке практически не реально.
* нет CICD, нет возможности запустить конкретную версию системы в контейнере. сложности с unit-testing.
* системы на хранимках не масштабируются горизонтально. нет технологии поставить 10 серверов СУБД и параллельно обрабатывать входящие запросы. для приложений горизонтальное масштабирование работает достаточно просто.

Веду проект преобразования инфраструктуры из 130+ систем в современную архитектуру. На таком количестве систем собрали все варианты костылей, проблем и извращений.
К примеру, в одной системе эмулировали MQ через таблицы в базе данных, в другой системе придумали эмулировать MQ через динамическую регистрацию URL куда сервер начинает стучаться по запросу. Гарантированная доставка? - нет, не слышали.
Еще изврат с отсутствием изоляции - несколько систем смотрят в одну и ту же базу.
Но самая жесть с системами написанными полностью на хранимках. Еще хуже, что эти системы напрямую лезут в БД соседей. Получается в соседних системах нельзя поменять структуру таблиц - может тихо отвалиться в где-то в хранимках.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

107. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (8), 14-Окт-22, 10:10 
Какие слова гуглить, чтобы понять что тут написано? Есть какие-то книги?
Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от john_erohin (?), 14-Окт-22, 11:29 
вот чего нагуглилось: habr.com/ru/company/lingualeo/blog/515530/

Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (8), 14-Окт-22, 12:39 
> Я предложил руководству полностью сменить философию бэкенда: перенести бизнес-логику в базу данных, а саму базу данных MySQL заменить на PostgreSQL.

Ну вот тут бизнес в БД пихают.

Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (8), 14-Окт-22, 12:40 
> Когда мы поделились планами с разработчиками, стало понятно, что команда не готова к изменениям. Большинство людей покинули компанию..

Продолжаю читать...

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

129. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от VoDA (ok), 14-Окт-22, 14:27 
Сорри, я уже олд скул ))
Наверняка вышли более качественные книги. Как минимум появились новые подходы типа микросервисов.

И да, если разработчик ни разу сам не делал кусок приложения, не фиксил падения прода, то многие архитектурные подходы выглядят излишними. Берем Agile и фигачим, а если не работает рефакторим. Так работает на малых + простых + не нагруженных системах. Если проектируем отказоустойчивую и масштабируемую систему, с обновлениями без остановки обслуживания пользователей, то архитектуру стоит продумать заранее. =)

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

117. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от 1 (??), 14-Окт-22, 13:52 
> Получается в соседних системах нельзя поменять структуру таблиц - может тихо отвалиться в где-то в хранимках.

А вы точно использовали реляционную БД ?

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

125. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от VoDA (ok), 14-Окт-22, 14:21 
Да, реляционка. И настройка меж серверами, что хранимка из одного сервера может выполнить SELECT из другого.
Разнесли по сервера - типа так посчитали правильнее изолировать системы друг от друга.
Ответить | Правка | Наверх | Cообщить модератору

131. "Релиз СУБД PostgreSQL 15"  +2 +/
Сообщение от Аноним (118), 14-Окт-22, 14:31 
У микросервисов такая же проблема, там для её решения обычно используют CDC тесты, тесты можно и в базе выполнять если что :-)
Ответить | Правка | Наверх | Cообщить модератору

141. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от 1 (??), 14-Окт-22, 16:08 
Я спрашивал к тому, что на РСУБД структура меняется очень просто. А если Вам вот прям необходимо сделать какое-то вычурное изменение, всегда на помощь приходят View.
Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

192. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Anonimous (?), 15-Окт-22, 17:38 
> работа на хранимках в БД заточена под массовую обработку

Из чего это следует?

> код тестовых стендов с хранимками через пару-тройку месяцев разработки расходятся с продакшеном

Почему то же самое не может случиться с трёхзвенкой?

> очень мало людей могут мыслить массовой обработкой и эффективно писать системы

Из чего это следует?

> нет CICD

Как это?

> нет возможности запустить конкретную версию системы в контейнере

Есть, вообще-то. Было бы желание.

> сложности с unit-testing.

Какие, например?

> системы на хранимках не масштабируются горизонтально. нет технологии поставить 10 серверов СУБД и параллельно обрабатывать входящие запросы

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

193. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Anonimous (?), 15-Окт-22, 17:39 
Вдогонку к предыдущему посту.
Shared-nothing архитектура? У того же Oracle есть ещё и Real Application Cluster.
Ответить | Правка | Наверх | Cообщить модератору

104. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от VoDA (ok), 14-Окт-22, 09:38 
Саммари: да - бизнес-логика прикладных систем только в приложении. RTFM современные архитектурные решения.

Есть исключение в виде репортинговых систем, где консолидируются и реконсилируются данные из множества разных зачастую не связанных систем. Хорошего решения для такой консолидации нет. Есть набор частных решений. К примеру: есть ETL, есть ELT, есть еще подходы. Где то используется преобразование на уровне потока данных (AirFlow, SSIS, Spark Streaming), где то уже в базе в виде хранимок.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

177. "Релиз СУБД PostgreSQL 15"  +1 +/
Сообщение от Прохожий (??), 15-Окт-22, 14:33 
Вася начал какую-то транзакцию, которая противоречит по логике транзакции Пети, начавшем её на другом сервере приложений. Где и как будет проходить контроль целостности и непротиворечивости данных?
Ответить | Правка | Наверх | Cообщить модератору

202. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Гентушник (ok), 16-Окт-22, 23:32 
Блокировки на уровне сервера приложений. Так например в 1С сделано :))))
Ответить | Правка | Наверх | Cообщить модератору

213. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Anonimous (?), 19-Окт-22, 05:43 
На каком из серверов? Мы же говорим о том, что серверов приложений может быть несколько.
Ответить | Правка | Наверх | Cообщить модератору

215. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Гентушник (ok), 19-Окт-22, 06:07 
> На каком из серверов? Мы же говорим о том, что серверов приложений
> может быть несколько.

На любом из этих двух или на третьем. Связь между ними обязательна.
Сначала пытаемся наложить "управляемую блокировку" (та что на уровне приложения). Для этого сервер приложений связывается с менеджером блокировок расположенным либо локально, либо на другом сервере приложений.

Дальше всё стандартно - менеджер блокировок возвращает результат что блокировка успешно наложена или что занято и пока ждём.
СУБД в этом процессе никак не участвует.

Менеджер блокировок по-сути знает схему БД с которой работает, но ничего не знает о данных.

Ответить | Правка | Наверх | Cообщить модератору

218. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Anonimous (?), 19-Окт-22, 06:26 
То есть, в итоге версионник превращается в блокировочника. А если Люся хочет начать при этом непротиворечивую транзакцию, будет ждать, пока блокировка не будет снята? Такое себе решение в плане производительности, за которую, вроде, и боремся.
Ответить | Правка | Наверх | Cообщить модератору

219. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Гентушник (ok), 19-Окт-22, 07:15 
> То есть, в итоге версионник превращается в блокировочника. А если Люся хочет
> начать при этом непротиворечивую транзакцию, будет ждать, пока блокировка не будет
> снята? Такое себе решение в плане производительности, за которую, вроде, и
> боремся.

Да, это блокировочник. А непротиворечивую это какую? Если Петя в транзакции меняет данные по товару "Болты", а Люся по товару "Гайки", то при правильно написанной управляемой блокировке они друг-другу мешать не будут.
А если работаем с одним товаром, то тут прикладная логика может быть разная и сложная (например контроль остатков на складе), так что извольте ждать.

Если Люся только читает данные (например отчёт по всем товарам), то управляемые блокировки ей накладывать вообще не надо. На уровне изоляции транзакций read committed (используется в 1С) непротиворечивость считанных данных будет соблюдаться на уровне СУБД если читать их один раз.

Ответить | Правка | Наверх | Cообщить модератору

165. "Релиз СУБД PostgreSQL 15"  +5 +/
Сообщение от microcoder (ok), 15-Окт-22, 00:02 
Бизнес логика может быть где угодно. Несогласным высылать повестки в военкомат
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру