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

"Релиз СУБД PostgreSQL 14"	+/–
Сообщение от opennews (?), 30-Сен-21, 19:58
После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 14.  Обновления для новой ветки будут выходить в течение пяти лет до ноября 2026 года... Подробнее: https://www.opennet.me/opennews/art.shtml?num=55891
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Релиз СУБД PostgreSQL 14"	+11 +/–
Сообщение от menangen (?), 30-Сен-21, 19:58
Пора переводить прод с мускула на постгрю!
Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	8. "Релиз СУБД PostgreSQL 14"	+4 +/–
	Сообщение от кукурузка (?), 30-Сен-21, 20:40
	> Если ваш "прот" можно вот так взять и перевести с MySQL на PostgreSQL, то это вызывает подозрение, что ваш "прот" - это сонник. А у этот комеент вызывает подозрения что вы не вкурсе как писать переносимые и расширяемые приложения и завязываетесь всегда на специфичные фишки всего вокруг. И это вызывает сильные подозрения что созданное вами пригодно для использования.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Релиз СУБД PostgreSQL 14"	+11 +/–
	Сообщение от Аноним (16), 30-Сен-21, 21:33
	Хм, тут как спросишь, какую СУБД выбрать в проект, так сразу начинается - "смотря какие задачи". А сейчас вдруг оказывается, что не надо фишки под задачи подбирать, пишите "переносимые".
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (25), 30-Сен-21, 22:17
	У товарища просто примитивный бэкенд и задачи. Соответственно там и отличий никаких нет. И нагрузка соответствующая. Конечно у всех БД свой SQL несовместимый SQL. Перевести базу данных очень сложно. Надо обмазываться тестами на SQL запросы и их производительностью. Такого, конечно, никто не делает.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от пох. (?), 30-Сен-21, 23:05
	Делают, почему же не делают.  Только делают там где понимают, нахрена ж страдать. Ну например мы тут перешли с оракла на... оракл, ага. 19й. Ну пару раз в опу дали... и немного пришлось отсо...ть с производительностью в некоторых узкоспециальных местах. Куды деваться, немодные версии снимают с поддержки.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (48), 01-Окт-21, 03:29
	У тебя похоже вообще задач нет, одни смузи на уме.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	45. "Релиз СУБД PostgreSQL 14"	–3 +/–
	Сообщение от Умпа (?), 01-Окт-21, 02:01
	>> "смотря какие задачи" Смотря КАКАЯ ЛИЦЕНЗИЯ!!! 300% местных далба обов пишет для собственной бабушки, по ходу. За иороженку. И, да! -- мой код работает _И_ под MySQL, _И_ под MS SQL, _И_ под Oracle. Окощько открыл мана в преференциях мана, указала мана база мана и мана окей нажимала. А постгресс -- МИТ. Поэтому он.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	84. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Steve Ballmer (?), 01-Окт-21, 11:51
	Там наверное select password from wp_users where username = 'vasya'
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Релиз СУБД PostgreSQL 14"	+10 +/–
	Сообщение от 2021 (?), 30-Сен-21, 22:05
	Мамкиным понторезам не лень 2k21 вместо 2021 набирать.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	26. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (16), 30-Сен-21, 22:17
	Папкиным манторезам не лень 2021 вместо 2021 набирать.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	27. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (25), 30-Сен-21, 22:19
	Ну они сейчас достаточно быстрые. На прошлом проекте в базу никто практически ни лез. Там даже кастомных индексов за запросы не было. Производительности хватало. И для многих проектов хватает.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	61. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Счетовод (?), 01-Окт-21, 08:01
	2k21 == 2210 != 2021
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

Часть нити удалена модератором

	89. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (89), 01-Окт-21, 12:10
	А тебя не обламывает раскладку переключать ради забивания"k"? Ты тратишь впустую свое время и совершаешь лишнее движение. Всякое лишнее движение не нужно, так как порождает хаос и тратит еще больше твоего времени в итоге. Лучше бы это время на что-то более полезное потратил. А так из закономерностей и секунды складываются в минуты/часы/дни/годы. Подобрал бы лучше кокой-нить мэйлпайл да пилил годный проект для хомо мыл. Ах да, так коммерционализация такая себе. Да. Поэтому ты лучше буш тут кочевряжится с написанием дат смайликами сношающихся поней, но делом не займешься. Пячалька.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

Часть нити удалена модератором

	108. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (108), 01-Окт-21, 16:36
	Дело не в твоём времени, а в том что твой текст выглядит плохо, неприятно читать.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от мимокро (?), 01-Окт-21, 20:21
	лавров.jpg
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	128. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (128), 02-Окт-21, 01:37
	2k во всём мире значит 2000. И это правильно! Двадцать с лишним лет назад умный человек создал оригинальное сокращение при описании проблемы двухтысячного года. (Ну и плюс Windows 2k). Оно экономит целых 2 (два!) символа при написании и является совершенно правильным. Третье  десятилетие это сокращение не даёт покоя пытливым и ищущим умам. 2k3, 2k8 от этих новаторов ещё можно как-то объяснить - экономия целого символа, плевать, что с потерей смысла. Но 2к21 ничего не экономит, т.е. смысла не имеет, кроме оригинальничанья, кривляния, тролинга. Это примерно как 2км8 или 2кг5 - вот сколько это в позиционной системе счисления? А то, что в автозамену поставил - молодец, целеустремлённый. И немного напоминает то, что в последнее время веб-макаки делают с программированием и с языками в частности.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	131. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от ptr128 (?), 02-Окт-21, 07:23
	Сопротивление среднего резистора 2002 Ом или все же 2200 Ом? https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRtqmzN... А у этого резистора сопротивление, по Вашему, 33 Ом. Или все же 330? https://sesaga.ru/wp-content/uploads/2012/05/rasshifrovka.jpg Разделитель "K" нужно употреблять все же понимая, что он обозначает, а не от балды. 2021 = 2K021, а 2K21 = 2210
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	28. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 30-Сен-21, 22:33
	> завязываетесь всегда на специфичные фишки всего вокруг Падаван явно мал и глуп У разных реализаций разный синтаксис. То, что в Oracle зовётся decode, в sap hana именуется map. Разный синтаксис преобразования типов, и так далее. Так вот, всё это мелочи, полностью нивелируемые ORM. Дальше чуть поинтереснее. Есть сущность sequence -- простейший счётчик. Так вот, в sqlite секвенсов нет и судя по тому, как автор др*чит на автоинкременты, в ближайшей перспективе не появится. В Машу и Мускуль секвенсы завезли "на днях" -- наконец-то как у взрослых дядей сделали. Дальше ещё прикольнее. Оказывается, что разные реализации по-разному реализуют MVCC. Постгря гадит под ноги, что потом героически вычищает autovacuum. InnoDB, как и Oracle, имеет rollback и redo сегменты, и в обоих применяется кластерный индекс. Эти различия приводят к различным стоимостям операций CRUD. Например, rollback в postgres практически бесплатный, но заставит вас страдать в InnoDB и Oracle. Update в постгресе всегда создаёт новую строку в таблице, и частые обновления заставят вас страдать. Кластерный индекс позволяет найти запись за O(1) (ну почти, там есть нюансы) , что особенно прикольно на большом числе JOIN. Всё это заставляет реализовывать логику приложения по-разному. Расскажешь, как нивелировать эти различия?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	31. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от kissmyass (?), 30-Сен-21, 22:48
	вместо счетчика использовать свой генератор айдишек базирующийся на времени (или рандомный типа GUID, если первичный ключ может быть не кластерным, так называемый Heap, привет SQL Server), про многоуровневые JOINы забудь, особенно в нагруженных СУБД или при шардинге (да и не нужны они вообще, разве что для пейджинга с сортировкой на стороне СУБД), кластерный индекс и некластерный имеют всегда O(n), зависит от размера таблицы и балансировки дерева, разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс, а потом саму запись, данные не находятся вместе с индексом, но один хрен это все O(n) и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от kai3341 (ok), 30-Сен-21, 23:28
	> вместо счетчика ... GUID Очень умная идея. Привет, фрагментация кластерного индекса и всей таблицы, развлекуха с пагинацией и прочие весёлости > про многоуровневые JOINы забудь, особенно в нагруженных СУБД Прикольно. А что взамен? Через N+1 делать? > кластерный индекс и некластерный имеют всегда O(n) Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс > разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс > данные не находятся вместе с индексом, но один хрен это все O(n) Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи > и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры Как вьюха или хранимая процедура решает проблему неизбежного создания новой записи при операции UPDATE в постгресе? Как вьюха или хранимая процедура позволяют обойти проблему дорогого ROLLBACK в InnoDB или Oracle?
	Ответить | Правка | Наверх | Cообщить модератору

	41. Скрыто модератором	+2 +/–
	Сообщение от kissmyass (?), 01-Окт-21, 00:44
	вот не надо из контекста выдергивать, я дословно написал: "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ", если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс > Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n)) > Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи что там взаимоисклющающего? кластерный индекс хранится вместе со строкой и задает порядок физического следования строк в таблице (поэтому он и должен быть последовательным во избежании проблем с перфомансом), а если индекс не кластерный, то он не хранится с данными и никак не определяет порядок следования строк в самой таблице не кластерному индексу нужно прочитать свои данные на диске, и только потом по полученному указателю надо найти физическое расположение данных, это всего лишь плюс 1 дисковая операция, но асимптотическая сложность для обоих индексов будет одинакова, именно поэтому она и называется асимптотической. если тебе надо еще подробнее, то это не ко мне, я считаю, что я уже и так с тобой задержался... и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца "покровительственный" тон!? очнись парень, ты обосpался...
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	–2 +/–
	Сообщение от kai3341 (ok), 01-Окт-21, 03:19
	> "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ", А, ну это точно решает проблему с пагинацией (нет) > если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс Как это решает проблему фрагментации самого индекса? > O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n)) Или используй О-нотацию правильно, или не используй вообще. "Ой ладно придираться, не O(N), а O(log N)" Разница между 4294967296 и 32 не имеет значения? > кластерный индекс хранится вместе со строкой Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1) > и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца > "покровительственный" тон!? очнись парень, ты обосpался... То есть по БД больше нечего сказать?
	Ответить | Правка | Наверх | Cообщить модератору

	56. Скрыто модератором	+2 +/–
	Сообщение от aa (?), 01-Окт-21, 07:03
	> А, ну это точно решает проблему с пагинацией (нет) а вы пагинацию делаете по первичному ключу? пользователь обычно хочет сортировку по чему-то более полезному, названию например, или цене. Зачем вобще первичный ключ при пагинации юзать?
	Ответить | Правка | Наверх | Cообщить модератору

	59. Скрыто модератором	+2 +/–
	Сообщение от Bx (ok), 01-Окт-21, 07:16
	> Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1) Ого, а можно поподробнее? Про нигде не хранится. И как с nullable, delete и прочей малозначимой херней типа сжатия быть?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	130. Скрыто модератором	+/–
	Сообщение от edo (ok), 02-Окт-21, 06:21
	> Если строка занимает > 123 байта, а значение первичного ключа 42, то расположение записи вычисляется > элементарно, и к самой записи мы переходим за O(1) И как оно вычисляется? Значение первичного ключа не равно номеру строки (и вообще может не быть числом).
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	49. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (48), 01-Окт-21, 03:32
	Обсмеялсо!
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	167. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 04-Окт-21, 10:20
	Мягко скажем, винегрет.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	40. "Релиз СУБД PostgreSQL 14"	–4 +/–
	Сообщение от Аноним (40), 01-Окт-21, 00:09
	Все нормальные люди используют orm а не пишут sql запросы и кот полностью переносимый А потом оно начинает тормозить и пишут запросы которые выполняться быстро но...
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	68. "Релиз СУБД PostgreSQL 14"	+3 +/–
	Сообщение от Аноним (68), 01-Окт-21, 08:59
	Все нормальные люди используют комбинацию подходов: используют ORM и Query Builders для банальных запросов, и пишут SQL там, где это требуется из соображений производительности. Универсальные ORM/QB хороши для рутинных вещей, но не способны сгенерировать оптимальные запросы и использовать специфику конкретной РСУБД.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от kai3341 (ok), 01-Окт-21, 12:21
	> и пишут SQL там, где это требуется из соображений производительности Открой для себя SQLAlchemy. Эта ORM позволяет извлечь как все преимущества императивного подхода, разбив ORM-запрос на модули и вынеся подзапросы отдельно, так при этом сохранить все преимущества SQL -- ты волен написать любой валидный запрос (почти. Не без косяков. Но они устранимы)
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 12:29
	А как там rollbacks-ы отрабатывают? Вот налепил ты объектов, решил их транзакционно поменять, поменял и тут -- хлоп -- в самом конце какое-то исключение вылезло. Как твоя Алхимия такую ситуацию обрабатывает? Состояние объектов откатит, как было до начала транзакции? А?
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:10
	Отрабатывает. Только я избегаю использовать ActiveRecord
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (68), 02-Окт-21, 10:20
	Не надо лепить объекты по принципу ActiveRecord для проектов сложнее бложика с комментариями. Надо использовать Data Mapper и принцип Aggregate Root из DDD. А роллбэки там даже распределенные есть, там отличный transaction manager.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	104. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от 3 (?), 01-Окт-21, 14:20
	внезапно, мир не ограничен петоном. и даже в мире питона этих орм штук 10, например джанговское, peewee и тд. из чего следует, что алхимия не универсально-могуча.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	120. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:13
	Количество != качество. С джангой сравнил. Сравнил бы в knex -- был бы другой разговор
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (108), 01-Окт-21, 16:40
	SQLAlchemy прекрасный ORM, один из лучших среди всех языков. Но даже на нём написать запрос на пару экранов это будет мучение.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	119. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:11
	Писал запросы на пару экранов. Не испытал мучения, а наоборот, писал с удовольствием. Как я сказал ранее, алхимия позволяет получить все преимущества императивного подхода (модульность, переиспользование кода и интроспекцию), не потеряв при этом преимуществ сырого SQL
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (68), 02-Окт-21, 10:18
	SQLAlchemy прекрасна. Но ее прекрасность обусловлена особенностями Питона, на другом языке такую же красоту не сделать. Можно попробовать изобразить что-то подобное на Kotlin с его DSL, но вряд ли у меня дойдут руки :(
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	94. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 12:30
	Сейчас, в общем-то, не важно как составлен запрос, если он логически корректен. С ОРМами другие проблемы.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	121. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:18
	Как раз важно. Есть 100500 способов составить запрос, получив на выходе один и тот же набор данных, но с различными стратегиями вычитывания данных. Производительность может различаться в разы. Например, SQL позволяет поместить подзапрос не только в `FROM`, но и в `SELECT`. Стратегия извлечения данных будет сильно разной
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:12
	Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 03-Окт-21, 15:53
	> Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан. Святая наивность. Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`. Главный оптимизатор запроса находится перед компом. Оптимизатор БД же тупенький конечный автомат, способный только предварительно вычислить константы, определить мощность множества (cardinality) и выбрать подходящий индекс (или неиспользование индекса -- бывает, так выгоднее).
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:29
	> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.> Это вы мне говорите, человеку с 20-летним стажем работы с СУБД? Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами. А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 05-Окт-21, 21:56
	>> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.> > Это вы мне говорите, человеку с 20-летним стажем работы с СУБД? FYI: стаж != экспертиза > Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Как бы да. Когда сам знаешь, где разбросаны грабли, ты их обходишь. Как я говорил, основной оптимизатор SQL-запроса этот запрос пишет. А оптимизаторы ошибаются. И иногда не просто ошибаются, а даже обсираются. Оптимизаторы очень не любят большое число JOIN на одном уровне -- Oracle не шмог в похожет случае. Кстати, основная причина промаха оптимизатора -- некорректная оценка мощности множества. > Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Вот отсюда подробнее. Где они там машинное обучение всунули, и, главное, зачем. Предоставьте пруфы. > Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами. Ну вообще да, в 99% случаев они неплохо справляются, если самому на грабли не наступать. > А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения. Я не говорю о том, что оптимизатор не может вообще ничего. И я согласен, оптимизаторы становятся всё умнее (или менее глупыми. Была ржака как-то -- в оптимизаторе MySQL нашли место, где rvalue не вычислялся на момент анализа запроса, хотя все данные для этого были). Оптимизаторы действительно творят невозможное. Помнится, запрос по временному ряду был очень весело ограничен: `WHERE TRUNC(event_created, 'MM') = :event_month` -- так вот, оптимизатор тут таки шмог, и вместо ожидаемого TABLE FULL ACCESS внезапно был INDEX RANGE SCAN. Да, он вычитал занные за весь год, но это сильно лучше полного чтения таблицы. Но ещё раз -- оптимизатор -- это программа, она не может ничего "выдумать". Задача оптимизатора -- сократить число чтений. Принятие же решения по сути является задачей поиска минимума. Он способен перебрать ограниченное число вариантов -- не больше, чем в него заложил программист. Оптимизатор, каким бы "умным" он ни был, останется тупеньким конечным автоматом. И очень странно, что я об этом рассказываю человеку, у которого "20 лет стажа работы с СУБД"
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от mos87 (ok), 01-Окт-21, 07:58
	если ты думаешь, что в риал ворлде (с)(тм) кто-то настолько заморачивается, что в одном проекте пишет скуль запросы сразу под разные ДБ (хотя всегда сидят на 1й одновременно), то ты либо 1) не знаешь о чем говоришь 2) не работаешь с запросами сложнее SELECT a_couple_of_columns FROM one_single_table
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	150. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:17
	Возьмём, например, 1С. Несколько мне известно, их продукт работает в реальном мире под разными СУБД, и там запросы сложнее, чем вы написали. Я работаю в компании, которая разрабатывает продукты (сложные и большие) под разные СУБД.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 03-Окт-21, 10:51
	Насколько мне известно там постгрес. но вполне может статься что бывает и разное. скорее всего может. только в одной конторе для одного проекта никто не будет расписывать запросы с учетом разницы между СУБД такой запрос выглядит сложным: SELECT col1||col2 FROM table ? вроде нет. Однако он может давать совершенно разные результаты на Oracle и сабже, а на других вовсе вызовет ошибку синтаксиса. ты вот сейчас серьёзно сказал, что люди для себя для своих проектов (или для клиентов, там обычно *всё равно подразумевается что СУБД известна и незаменяема*) сидя на одной СУБД будут писать этот запрос так: SELECT НЕКАКАЯ_ФУНКЦИЯ_ОПРЕДЕЛЯЮЩАЯ_ВЫПОЛНЯЮЩУЮ_СУБД( есди_оракл то col1||col2, если_пг COALESCE( col1, 0 )||COALESCE( col2, '0' ), если_мускль CONCANT( col1, col2 ), если_голимый col1+col2 ) FROM table
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:20
	Смотреть в сторону ORB.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 05-Окт-21, 20:32
	зачем? (и что это?)
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:37
	Object Relational Bridge. Зачем смотреть? Есть у вас сложный продукт, который однако, легко разбиваются на модули. Можете целиком продавать все модули (крупным денежным клиентам) вместе с Oracle. А можете отдельные модульки с PostgreSQL мелким небогатым. В итоге у вас более полный охват рынка.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от letsmac (ok), 01-Окт-21, 09:45
	Ну если у тебя SQL это тупой Store без хранимых процедур и ты слово профайлер слышишь в первый раз - то тогда да, это не проблема. Купи побольше процов в облаке и всё работать будет.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	77. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 11:10
	Это ваше "переносимое и расширяемое", если ему пофиг на транзакционное ядро, которое под ним лежит, скорее всего никакие СУБД вообще не использует. ИСАМ и реляционные БД с полноценным WAL-ом и MVCC это абсолютно разные вселенные. Если ИСАМ был выбран осознанно, то переводить его на реляционные схемы c MVCC нет никакого смысла -- будет просто тупо медленней и в разы более толсто.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	135. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ptr128 (?), 02-Окт-21, 07:49
	> завязываетесь всегда на специфичные фишки А варианты? Хотите приведу целый ряд запросов, которые вообще без изменений легко выполняются и в MS SQL и в PostgreSQL, но во втором без модификации уходят в глухой table scan? Обзор тут: https://www.endpoint.com/blog/2020/06/postgresql-improve-gro.../ Я уже молчу о временных и, тем более, глобальных временных таблицах. Тут уже в каждой СУБД свои заморочки, требующие при миграции, нередко, просто переписывания кода.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	34. "Релиз СУБД PostgreSQL 14"	+5 +/–
	Сообщение от й (?), 30-Сен-21, 23:17
	нооо мооой прооот! свитый из багов и снов всем моим бедам назло вовсе не так уж плох
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от Док (?), 02-Окт-21, 12:19
	Оо подошли старперские оптимизации бесконтактного боя
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от kissmyass (?), 30-Сен-21, 21:49
	зачем?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	47. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (48), 01-Окт-21, 03:27
	Пора тебе побеспокоиться за свой тыл.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	125. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от FSA (??), 01-Окт-21, 20:43
	> Пора переводить прод с мускула на постгрю! Не стоит. Но стоит задуматься о создании нового прода уже на PostgreSQL. Я не особый спец. Любитель. Но приятно было отказаться от MySQL. Сначала привыкаешь к особенностям. Потом учишься делать хитрые запросы. Потом балуешься с json, которые участвуют в индексах. Потом понимаешь, что для того, чтобы сделать то, что позволяет PostgreSQL на MySQL, мягко говоря, сложно. Но если ты просто меняешь БД в настройках своей CMS - то это не миграция, а херня. Не стоит. Твой код должен быть написан именно для PostgreSQL с учётом его особенностей. Код не может быть заточен и под MySQL и PostgreSQL. Это компромисс для эникейщиков, чтобы поставить систему на любой сервер.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Релиз СУБД PostgreSQL 14"	+5 +/–
Сообщение от InuYasha (??), 30-Сен-21, 20:01
Слоник - это вещь! Моё уважение проекту.
Ответить | Правка | Наверх | Cообщить модератору

4. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от Аноним (89), 30-Сен-21, 20:02
Надеюсь до постгри раст не доберется!
Ответить | Правка | Наверх | Cообщить модератору

	6. "Релиз СУБД PostgreSQL 14"	–5 +/–
	Сообщение от Аноним (6), 30-Сен-21, 20:11
	А было бы неплохо, повышение качества еще никому не вредило
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от Аноним (7), 30-Сен-21, 20:24
	Переписывание затянется в бесконечность.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Релиз СУБД PostgreSQL 14"	+4 +/–
	Сообщение от Аноним (11), 30-Сен-21, 20:56
	Посмотрите сколько пунктов в стандарте MISRA. Память лишь один пункт из многих. А понты из закорючек в одну строчку наоборот нежелательно. Для Раста есть подобный стандарт?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	12. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (12), 30-Сен-21, 21:04
	Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - значит безопасно. Миллионы растоманов не могут ошибаться.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (17), 30-Сен-21, 21:33
	Зато на Расте синтаксис подталкивает к тому чтобы писать говнокод. А говнокод можно переписывать бесконечно. Это же рай для тех кто любит все переписывать бесконечно!
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от leap42 (ok), 01-Окт-21, 05:38
	> Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - значит безопасно. Миллионы растоманов не могут ошибаться. Mozilla, помню, говорила обратное🤔
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	14. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Анонн (?), 30-Сен-21, 21:31
	Посмотрите внимательней на требования MISRA и список тех, кто этой MISR'е следует. Даже ядро линя, а оно существенно более критично чем постгресс, ему не соответствует. А вы про прикладной софт...
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	69. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (69), 01-Окт-21, 09:17
	> Даже ядро... не соответствует Это хорошо или плохо?
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Анонн (?), 01-Окт-21, 12:10
	С точки зрения надежности - плохо. Но есть мнения что ядро какое оно сейчас вообще невозможно написать с такими ограничениями. Как минимум пришлось бы заставить всех драйверописателей и остальных, чей код тянется в ядро, следовать этим ограничениям. А это нереально.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от An (??), 01-Окт-21, 12:38
	В этом проекте на С с качеством все в порядке. Давайте не портить его. rust уже влез в linux. Неплохо бы сначала посмотреть, что из этого получится.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	146. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Alladin (?), 03-Окт-21, 00:05
	Все давно придумано за вас. И да, есть.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	105. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (105), 01-Окт-21, 15:01
	чо за постгри?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

9. "Релиз СУБД PostgreSQL 14"	+2 +/–
Сообщение от кукурузка (?), 30-Сен-21, 20:41
Отличный проект. Успехов.
Ответить | Правка | Наверх | Cообщить модератору

10. "Релиз СУБД PostgreSQL 14"	–2 +/–
Сообщение от Аноним (10), 30-Сен-21, 20:52
Бредовый синтаксис. У них всегда были с этим проблемы и вот опять.
Ответить | Правка | Наверх | Cообщить модератору

	64. "Релиз СУБД PostgreSQL 14"	–3 +/–
	Сообщение от mos87 (ok), 01-Окт-21, 08:19
	почему этот нереально жырный и унылый троллинг не удаляется? троллботнумшаблон не заходит?
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от лютый жабби__ (?), 01-Окт-21, 11:08
	>Бредовый синтаксис. У них всегда были с этим проблемы и вот опять. у постгреса похоже в штате больше форумных ботов, чем прогеров. :) иначе я просто не понимаю откуда  столько минусов у любой критики слонопотамов. сам пользовался слоном много лет назад, но не понимаю как можно остаться на постгресе хотябы 1 раз пощупав монго ) как жигуль vs нормальная япошка )
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	110. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от Аноним (108), 01-Окт-21, 16:43
	> я просто не понимаю Может быть проблема в тебе, что если ты не прав, не приходило такое в голову?
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от лютый жабби__ (?), 02-Окт-21, 07:41
	>Может быть проблема в тебе не думаю. в могучем слоне всё так же - если на диске занято больше 60% то vacuum full уже не сделать? )
	Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от Аноним (13), 30-Сен-21, 21:21
Уже обновился на Убунте. Теперь еще численные типы могут содержать значение Infinity.
Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз СУБД PostgreSQL 14"	–6 +/–
Сообщение от Аноним (17), 30-Сен-21, 21:31
Мастер-Мастер подвезли? Нет? Тогда сразу в гарбедж.
Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от leap42 (ok), 01-Окт-21, 05:40
	> Мастер-Мастер подвезли? Нет? Тогда сразу в гарбедж. лол, зочем? он же ничего кроме боли не дает
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от mos87 (ok), 01-Окт-21, 08:17
	тебе твой мастер не нравится? слишком белый?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	92. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (92), 01-Окт-21, 12:28
	Ему тройничок подавай
	Ответить | Правка | Наверх | Cообщить модератору

29. "Релиз СУБД PostgreSQL 14"	+2 +/–
Сообщение от One More Аноним (?), 30-Сен-21, 22:36
>> Повышена эффективность работы индексов B-tree и решена проблема с разрастанием индексов при частом обновлении таблиц. finally
Ответить | Правка | Наверх | Cообщить модератору

33. "Релиз СУБД PostgreSQL 14"	–1 +/–
Сообщение от пох. (?), 30-Сен-21, 23:06
vacuum full надеюсь наконец-то запретили и объявили окончательно и бесповоротно deprecated? А, нет, померещилось...
Ответить | Правка | Наверх | Cообщить модератору

	50. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (50), 01-Окт-21, 04:40
	А смысл?
	Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз СУБД PostgreSQL 14"	–1 +/–
Сообщение от PetrG (ok), 30-Сен-21, 23:22
Нужное. Разрешаю дальнейшую разработку. А то тут некоторые повадились ненужное без разрешения кодить...
Ответить | Правка | Наверх | Cообщить модератору

	147. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Alladin (?), 03-Окт-21, 00:06
	Зачем спрашивать у вас разрешение, вы кто дядя?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от petrg (ok), 03-Окт-21, 22:30
	Q.E.D. Хочу opennet но для взрослых. За*был этот десткий сад в комментариях.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от petrg (ok), 03-Окт-21, 22:31
	А по моему хорошая шутка получилась.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

37. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от Аноним (37), 30-Сен-21, 23:29
Ещё никто не спрашивал про пакеты и undo?
Ответить | Правка | Наверх | Cообщить модератору

	81. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 11:29
	Подобие пакетов есть. Подобие анду-сегментов тоже есть. Но больше похоже на версионное хранилище МС Сиквела, чем на Оракловую реализацию. Да и не сильно надо, вообще-то. Вот вам анду зачем? Для чего-то вроде флэшбэка по анду?
	Ответить | Правка | Наверх | Cообщить модератору

38. "Релиз СУБД PostgreSQL 14"	–2 +/–
Сообщение от Ilya Indigo (ok), 01-Окт-21, 00:06
> В новых установках по умолчанию обеспечено применение парольной аутентификации с использованием метода SCRAM-SHA-256 вместо md5 (параметр "password_encryption" при генерации postgresql.conf теперь устанавливается в значение 'scram-sha-256'). Ну наконец-то каждый раз при установке не придётся это ручками изменять, ждал этого давно.
Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз СУБД PostgreSQL 14"	–3 +/–
Сообщение от Ilya Indigo (ok), 01-Окт-21, 00:09
> SELECT * FROM test WHERE details['attributes']['size'] = '"medium"' А чем старый не устроил? SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'
Ответить | Правка | Наверх | Cообщить модератору

	51. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (50), 01-Окт-21, 04:42
	Фронтендеры пугаются.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Ilya Indigo (ok), 01-Окт-21, 10:26
	> Фронтендеры пугаются. Что фронтендеры вообще в SQL-е забыли, с ним работают только бекеры?
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от Аноним (108), 01-Окт-21, 16:48
	Javascript теперь и на беке давно :-)
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Фёдор (?), 01-Окт-21, 07:05
	Более читабельный. Это уже наркомания какая-то: SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	65. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 01-Окт-21, 08:21
	пихать в скуль вот это всё - это и есть наркомания скуль придуман для относительно простеньких декларативненьких запросиков. ими и должен заниматься. попытка запихать вселенную в скуль приводит к тому, что у отвёртки из авторемнабора вдруг ручка в виде руля - потому что у машины тоже руль.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Наме (?), 01-Окт-21, 11:16
	Декларативные не равно простенькие. Коррелированные подзапросы с окнами и свёртками сложно назвать простенькими. При этом они крайне немногословны относительно императивных реализаций.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 02-Окт-21, 12:26
	само собой, ибо вся мякотка скрыта в СУБД но они и обычно в хвосте переносимости и самое главное обычно запросы содержащие такое не ограничиваются и малым размером. а это уже всяко плохо. неуправляемо, неподдерживаемо. если 5 строчный запрос с окном - это неплохо. horses for courses.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Ilya Indigo (ok), 01-Окт-21, 10:28
	> Более читабельный. > Это уже наркомания какая-то: > SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium' Особенно невозможность разименовать json(b) в которой нужно оборачивать сравниваемую строку в двойные кавычки. который является символом экранирования в pqsql. Офигенно читаемо!
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	112. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (108), 01-Окт-21, 16:51
	У этих операторов разный тип результата (-> json, ->> text), а у оператора индексации массива способа поменять тип кроме оборачивания в CAST нет.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	148. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Alladin (?), 03-Окт-21, 00:07
	Почему же, +- как в php.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	127. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от edo (ok), 02-Окт-21, 00:08
	> SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium' Мне интересно, как эта наркомания вообще пролезла в когда-то человекочитаемый sql '["a", "b", "c"]'::jsonb ?& array['a', 'b'] '{"a": {"b": ["foo","bar"]}}'::json #>> '{a,b,1}'
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

55. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от Аноним (55), 01-Окт-21, 06:58
Я, если честно, вообще не знаю, зачем до сих пор нужен SQL, если в него приходится пихать все больше и больше фишек обычных языков. Давайте уже оставим SQL в покое, но встроим в него какую-нибудь Джаву, чтобы прямо в запрос скрипт всовывать.
Ответить | Правка | Наверх | Cообщить модератору

	58. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от m (??), 01-Окт-21, 07:09
	Уже есть встроенные языки plsql, perl, ...
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 01-Окт-21, 08:24
	да, это просто традиция что ДБшники как секта всё пихают в свою СУБД и ограничены только её возможностями. раньше СУБД были как отдельная ОС, теперь же и нормальные обычные приложения (на том же Перл или простихоспаде жабе) работают с БД не хуже, благо библиотеки/обвязки нынчо достаточно развиты. если что-то зело специфическое и аццки оптимизированное надо, тогда да. Но 90%ам это не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Наме (?), 01-Окт-21, 11:24
	У СУБД свои задачи, у фронтэнда и контроллеров -- свои. Манипулировать данными в десятки раз проще на Сиквеле, а обрабатывать всякие приведения форматов удобнее другими инструментами. ОРМ в реальных применениях годны только для самых простейших вызовов. И не потому, что делают плохие запросы, а потому, что нет ни одного массового императивного языка, у которого была бы транзакционная модель памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от mos87 (ok), 02-Окт-21, 12:42
	да, но бизлогика на скуле - это неуправляемая mess я лично за то чтобы сырые данные с мин обработки хранить в иерархическом виде, а то что нужно крутить, сравнивать, перекрёстно-линковать - это в таблички, где этому и место.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Alex (??), 01-Окт-21, 10:57
	Мне это не нужно,я этого не понимаю. Значит никто не понимает и никому этотне нужно! Дураки какие-то деньги тратят на разработку никому ненужных вещей.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	79. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 11:18
	Потому что в Сиквеле двумя фразами можно сделать то, что на императивных языках делается тысячами строк всяких библиотек.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	85. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от nobody (??), 01-Окт-21, 11:56
	Оракуль пытался, ещё с 90-х. Чё-т не очень жаба SQL или хотя бы PL/SQL заменила
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	86. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 12:04
	Сиквел ничем не заменить. ПЛ хорошо подружен с Сиквелом. А Ява -- она не для замены ни того, ни другого. Просто на ней можно делать то, что на ПЛ делать затруднительно или реализация получается жутковатая.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ptr128 (?), 02-Окт-21, 07:54
	Java давно есть https://github.com/tada/pljava Но заменить SQL она все равно не в состоянии. Парадигма другая.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

70. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от pofigist (?), 01-Окт-21, 09:43
Зачем все это в SQL DB?
Ответить | Правка | Наверх | Cообщить модератору

	113. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (108), 01-Окт-21, 16:52
	Для функциональности.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от pofigist (?), 03-Окт-21, 19:37
	Какое отношение имт все эти свистгперделки к функционалу SQL DB?
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Яхз (?), 01-Окт-21, 23:41
	Чтобы не таскать данные между базой и чем-то ещё по сети туда-сюда
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

75. "Релиз СУБД PostgreSQL 14"	–3 +/–
Сообщение от лютый жабби__ (?), 01-Окт-21, 11:04
>  SELECT ('{ "postgres": { "release": 14 }}'::jsonb)['postgres']['release']; о мама мия... почему эти люди не могут посмотреть как сделано у нормальных людей? у монги апи уже 5 лет назад было разрывающе удобнее подобного бреда....
Ответить | Правка | Наверх | Cообщить модератору

	114. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (108), 01-Окт-21, 16:58
	API на javascript? Как вы себе представляете добавление javascript в SQL?
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от лютый жабби__ (?), 02-Окт-21, 07:43
	>SQL это какое-то гомно из 70-х прошлого века? Зачем за него цепляться?
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:39
	Да будет тебе известно, что это из 70-х снабжается математическим аппаратом и вообще стройной теорией обработки данных. Где вы такие "прогрессивные" только беретесь-то?
	Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз СУБД PostgreSQL 14"	–4 +/–
Сообщение от МояВенда (ok), 01-Окт-21, 11:42
После добавления в монгодб транзакций, постгрес стал официально не нужен.
Ответить | Правка | Наверх | Cообщить модератору

	87. "Релиз СУБД PostgreSQL 14"	+3 +/–
	Сообщение от Наме (?), 01-Окт-21, 12:05
	Монго давно умер. И нет там никаких "транзакций" и быть не может в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (99), 01-Окт-21, 13:19
	Я аш смузи подавился. Вы все врёте!
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от МояВенда (ok), 01-Окт-21, 13:59
	С сайта монги: "MongoDB 5.0 is the latest generation of the database most wanted by developers". Это называется давно умер? MOST WANTED, Карл! Starting in version 4.0, MongoDB provides the ability to perform multi-document transactions against replica sets. Хоть сам и сижу на постгре, но рассматриваю ее исключительно как легаси.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	103. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от пох. (?), 01-Окт-21, 14:04
	На сарае еще и не такое написано, но там - дрова.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (105), 01-Окт-21, 15:02
	чо за постгре?
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	115. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (108), 01-Окт-21, 17:00
	Афира почитайте, а то может оказаться что транзакции не совсем транзакционны как сейчас.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	107. "Релиз СУБД PostgreSQL 14"	–3 +/–
	Сообщение от лютый жабби__ (?), 01-Окт-21, 16:16
	>Монго давно умер. И нет там никаких "транзакций" и быть не может в принципе. глупый слонопотамщик не понимает, что в монге данные немного по другому хранятся и по существу там были "транзакции" всегда, т.к. в монге не нужно атомарно редактировать по несколько размазанных на несколько таблиц строк ) т.е. атомарность это КОСТЫЛЬ реляционных субд, а не мегафича!  ) ну а сейчас и транзакции давно есть, с 4.0 кажись
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	116. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (108), 01-Окт-21, 17:05
	https://aphyr.com/tags/mongodb Транзакции не имеют никакого отношения к тому как физически хранятся данные, это логическая конструкция и атомарность записи объекта в файл не является достаточной для реализации всех уровней изоляции транзакций.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от МояВенда (ok), 01-Окт-21, 17:38
	Причем тут вообще файлы? Монго гарантирует атомарность на уровне документа (или нескольких документов если использовать транзакцию). Физическая реализация может быть какой угодно.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от лютый жабби__ (?), 02-Окт-21, 07:47
	>Транзакции не имеют никакого отношения к тому как физически хранятся данные Транзакции в 99% случаев не нужны. Либо нужны, но тормозят больше чем нужно...
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	152. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:44
	Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании только. Не поймут твой "прогрессивный" подход.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ыы (?), 03-Окт-21, 11:51
	Ну почему каком-нибудь... Скорее всего в Сбербанке.. Он под себя подомнет весь ИТ в Россиии... :)
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от лютый жабби__ (?), 03-Окт-21, 18:51
	>Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании только А ты не ляпни про постгрес на собеседовании в банке ))
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	163. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ыы (?), 03-Окт-21, 19:17
	Иногда стоит промолчать а не демонстрировать уровень своей компетентности https://www.cnews.ru/news/top/2021-03-23_podderzhivat_za_250...
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ыы (?), 03-Окт-21, 11:50
	А вы уверены что транзакций там нет? Может вам просто предоставляют механизм неких гарантий, а под капотом там неявно вызываемые автоматические транзакции как раз и работают?
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

97. "Релиз СУБД PostgreSQL 14"	+1 +/–
Сообщение от Аноним12345 (?), 01-Окт-21, 12:47
Респект
Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз СУБД PostgreSQL 14"	–3 +/–
Сообщение от iZEN (ok), 01-Окт-21, 19:11
Чем PostgresQL 14.0 лучше Firebird 4.0?
Ответить | Правка | Наверх | Cообщить модератору

	123. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Alladin (?), 01-Окт-21, 20:06
	Версия больше) Ну але гараж, что за вопросы странные... Чем гугл лучше яндекса и давай отвечай сразу в одном сообщении.. кто так делает..
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ыы (?), 02-Окт-21, 19:58
	Не лучше а хуже... И ответ на этот вопрос вы узнаете сразу же как американский сегмент отключат от интернета...
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:55
	Вы хотели сказать "российский". С чего бы американцам отключаться от Интернета. Они подобной фигнёй (изоляционизмом) не страдают. Да и вообще, вон, есть российская контора, которая пилит свою редакцию PostgreSQL.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ыы (?), 03-Окт-21, 10:21
	Есть такой список, "страны угрожающие американскому образу жизни". Это часть доктрины национальной безопасности США. И с каждым годом этот список все все шире... А после строительства Северного Потока- он станет еще шире... С этими странами американские компании не могут торговать, вести отношения... Так что не исключена ситуация когда США самоизолируется от всего мира... ну кроме ее сателлитов :)
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:32
	Пока из таких стран - Россия, Китай и КНДР, насколько мне известно. Но, может, я чего не знаю, дополняйте список.
	Ответить | Правка | Наверх | Cообщить модератору

140. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от Док (?), 02-Окт-21, 12:25
Наверное хорошая штука но ставить не буду никогда тк ее разрабы судя по документации ненавидят заранее всех кто будет ее использовать и всех кто хочет найти примеры)
Ответить | Правка | Наверх | Cообщить модератору

	143. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (-), 02-Окт-21, 13:35
	Очень странный довод. По мне, так у них просто замечательно вылизанная документация - у всех бы так было.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:58
	Довольно хреновая у них документация. Архитектура, например, вообще нигде не описана. Приходится с миру по нитке скрести. Да и многие особенности работы тоже нигде не упоминаются.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от ыы (?), 03-Окт-21, 10:37
	Так исходный код же есть... Мало? :)
	Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от ыы (?), 02-Окт-21, 19:42
а когда уже нормальный active/active кластер завезут?
Ответить | Правка | Наверх | Cообщить модератору

155. "Релиз СУБД PostgreSQL 14"	+/–
Сообщение от Прохожий (??), 03-Окт-21, 06:00
А когда уже direct io, undo нормальный завезут.
Ответить | Правка | Наверх | Cообщить модератору

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

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