После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 14. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2026 года...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55891
Пора переводить прод с мускула на постгрю!
> Если ваш "прот" можно вот так взять и перевести с MySQL на PostgreSQL, то это вызывает подозрение, что ваш "прот" - это сонник.А у этот комеент вызывает подозрения что вы не вкурсе как писать переносимые и расширяемые приложения и завязываетесь всегда на специфичные фишки всего вокруг. И это вызывает сильные подозрения что созданное вами пригодно для использования.
Хм, тут как спросишь, какую СУБД выбрать в проект, так сразу начинается - "смотря какие задачи". А сейчас вдруг оказывается, что не надо фишки под задачи подбирать, пишите "переносимые".
У товарища просто примитивный бэкенд и задачи. Соответственно там и отличий никаких нет. И нагрузка соответствующая.Конечно у всех БД свой SQL несовместимый SQL. Перевести базу данных очень сложно.
Надо обмазываться тестами на SQL запросы и их производительностью. Такого, конечно, никто не делает.
Делают, почему же не делают. Только делают там где понимают, нахрена ж страдать.Ну например мы тут перешли с оракла на... оракл, ага. 19й. Ну пару раз в опу дали... и немного пришлось отсо...ть с производительностью в некоторых узкоспециальных местах. Куды деваться, немодные версии снимают с поддержки.
У тебя похоже вообще задач нет, одни смузи на уме.
>> "смотря какие задачи"Смотря КАКАЯ ЛИЦЕНЗИЯ!!!
300% местных далба обов пишет для собственной бабушки, по ходу.
За иороженку.И, да! -- мой код работает _И_ под MySQL, _И_ под MS SQL, _И_ под Oracle.
Окощько открыл мана в преференциях мана, указала мана база мана и мана окей нажимала.
А постгресс -- МИТ.
Поэтому он.
Там наверное select password from wp_users where username = 'vasya'
Мамкиным понторезам не лень 2k21 вместо 2021 набирать.
Папкиным манторезам не лень 2021 вместо 2021 набирать.
Ну они сейчас достаточно быстрые. На прошлом проекте в базу никто практически ни лез. Там даже кастомных индексов за запросы не было. Производительности хватало.И для многих проектов хватает.
2k21 == 2210 != 2021
А тебя не обламывает раскладку переключать ради забивания"k"?
Ты тратишь впустую свое время и совершаешь лишнее движение. Всякое лишнее движение не нужно, так как порождает хаос и тратит еще больше твоего времени в итоге. Лучше бы это время на что-то более полезное потратил. А так из закономерностей и секунды складываются в минуты/часы/дни/годы.Подобрал бы лучше кокой-нить мэйлпайл да пилил годный проект для хомо мыл. Ах да, так коммерционализация такая себе. Да. Поэтому ты лучше буш тут кочевряжится с написанием дат смайликами сношающихся поней, но делом не займешься. Пячалька.
Дело не в твоём времени, а в том что твой текст выглядит плохо, неприятно читать.
лавров.jpg
2k во всём мире значит 2000.
И это правильно!
Двадцать с лишним лет назад умный человек создал оригинальное сокращение при описании проблемы двухтысячного года. (Ну и плюс Windows 2k). Оно экономит целых 2 (два!) символа при написании и является совершенно правильным. Третье десятилетие это сокращение не даёт покоя пытливым и ищущим умам. 2k3, 2k8 от этих новаторов ещё можно как-то объяснить - экономия целого символа, плевать, что с потерей смысла. Но 2к21 ничего не экономит, т.е. смысла не имеет, кроме оригинальничанья, кривляния, тролинга. Это примерно как 2км8 или 2кг5 - вот сколько это в позиционной системе счисления? А то, что в автозамену поставил - молодец, целеустремлённый. И немного напоминает то, что в последнее время веб-макаки делают с программированием и с языками в частности.
Сопротивление среднего резистора 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
> завязываетесь всегда на специфичные фишки всего вокругПадаван явно мал и глуп
У разных реализаций разный синтаксис. То, что в Oracle зовётся decode, в sap hana именуется map. Разный синтаксис преобразования типов, и так далее. Так вот, всё это мелочи, полностью нивелируемые ORM.
Дальше чуть поинтереснее. Есть сущность sequence -- простейший счётчик. Так вот, в sqlite секвенсов нет и судя по тому, как автор др*чит на автоинкременты, в ближайшей перспективе не появится. В Машу и Мускуль секвенсы завезли "на днях" -- наконец-то как у взрослых дядей сделали.
Дальше ещё прикольнее. Оказывается, что разные реализации по-разному реализуют MVCC. Постгря гадит под ноги, что потом героически вычищает autovacuum. InnoDB, как и Oracle, имеет rollback и redo сегменты, и в обоих применяется кластерный индекс. Эти различия приводят к различным стоимостям операций CRUD. Например, rollback в postgres практически бесплатный, но заставит вас страдать в InnoDB и Oracle. Update в постгресе всегда создаёт новую строку в таблице, и частые обновления заставят вас страдать. Кластерный индекс позволяет найти запись за O(1) (ну почти, там есть нюансы) , что особенно прикольно на большом числе JOIN.
Всё это заставляет реализовывать логику приложения по-разному. Расскажешь, как нивелировать эти различия?
вместо счетчика использовать свой генератор айдишек базирующийся на времени (или рандомный типа GUID, если первичный ключ может быть не кластерным, так называемый Heap, привет SQL Server), про многоуровневые JOINы забудь, особенно в нагруженных СУБД или при шардинге (да и не нужны они вообще, разве что для пейджинга с сортировкой на стороне СУБД), кластерный индекс и некластерный имеют всегда O(n), зависит от размера таблицы и балансировки дерева, разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс, а потом саму запись, данные не находятся вместе с индексом, но один хрен это все O(n)и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры
> вместо счетчика ... GUIDОчень умная идея. Привет, фрагментация кластерного индекса и всей таблицы, развлекуха с пагинацией и прочие весёлости
> про многоуровневые JOINы забудь, особенно в нагруженных СУБД
Прикольно. А что взамен? Через N+1 делать?
> кластерный индекс и некластерный имеют всегда O(n)
Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс
> разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс
> данные не находятся вместе с индексом, но один хрен это все O(n)Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи
> и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры
Как вьюха или хранимая процедура решает проблему неизбежного создания новой записи при операции UPDATE в постгресе? Как вьюха или хранимая процедура позволяют обойти проблему дорогого ROLLBACK в InnoDB или Oracle?
вот не надо из контекста выдергивать, я дословно написал:"или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ",
если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс
> Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс
O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n))
> Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи
что там взаимоисклющающего? кластерный индекс хранится вместе со строкой и задает порядок физического следования строк в таблице (поэтому он и должен быть последовательным во избежании проблем с перфомансом), а если индекс не кластерный, то он не хранится с данными и никак не определяет порядок следования строк в самой таблице
не кластерному индексу нужно прочитать свои данные на диске, и только потом по полученному указателю надо найти физическое расположение данных, это всего лишь плюс 1 дисковая операция, но асимптотическая сложность для обоих индексов будет одинакова, именно поэтому она и называется асимптотической.
если тебе надо еще подробнее, то это не ко мне, я считаю, что я уже и так с тобой задержался...
и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца
"покровительственный" тон!? очнись парень, ты обосpался...
> "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ",А, ну это точно решает проблему с пагинацией (нет)
> если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс
Как это решает проблему фрагментации самого индекса?
> O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n))
Или используй О-нотацию правильно, или не используй вообще.
"Ой ладно придираться, не O(N), а O(log N)"
Разница между 4294967296 и 32 не имеет значения?> кластерный индекс хранится вместе со строкой
Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1)
> и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца
> "покровительственный" тон!? очнись парень, ты обосpался...То есть по БД больше нечего сказать?
> А, ну это точно решает проблему с пагинацией (нет)а вы пагинацию делаете по первичному ключу?
пользователь обычно хочет сортировку по чему-то более полезному, названию например, или цене.
Зачем вобще первичный ключ при пагинации юзать?
> Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1)Ого, а можно поподробнее? Про нигде не хранится. И как с nullable, delete и прочей малозначимой херней типа сжатия быть?
> Если строка занимает
> 123 байта, а значение первичного ключа 42, то расположение записи вычисляется
> элементарно, и к самой записи мы переходим за O(1)И как оно вычисляется?
Значение первичного ключа не равно номеру строки (и вообще может не быть числом).
Обсмеялсо!
Мягко скажем, винегрет.
Все нормальные люди используют orm а не пишут sql запросы и кот полностью переносимый
А потом оно начинает тормозить и пишут запросы которые выполняться быстро но...
Все нормальные люди используют комбинацию подходов: используют ORM и Query Builders для банальных запросов, и пишут SQL там, где это требуется из соображений производительности.Универсальные ORM/QB хороши для рутинных вещей, но не способны сгенерировать оптимальные запросы и использовать специфику конкретной РСУБД.
> и пишут SQL там, где это требуется из соображений производительностиОткрой для себя SQLAlchemy. Эта ORM позволяет извлечь как все преимущества императивного подхода, разбив ORM-запрос на модули и вынеся подзапросы отдельно, так при этом сохранить все преимущества SQL -- ты волен написать любой валидный запрос (почти. Не без косяков. Но они устранимы)
А как там rollbacks-ы отрабатывают? Вот налепил ты объектов, решил их транзакционно поменять, поменял и тут -- хлоп -- в самом конце какое-то исключение вылезло. Как твоя Алхимия такую ситуацию обрабатывает? Состояние объектов откатит, как было до начала транзакции? А?
Отрабатывает. Только я избегаю использовать ActiveRecord
Не надо лепить объекты по принципу ActiveRecord для проектов сложнее бложика с комментариями.Надо использовать Data Mapper и принцип Aggregate Root из DDD.
А роллбэки там даже распределенные есть, там отличный transaction manager.
внезапно, мир не ограничен петоном.
и даже в мире питона этих орм штук 10, например джанговское, peewee и тд.
из чего следует, что алхимия не универсально-могуча.
Количество != качество. С джангой сравнил.
Сравнил бы в knex -- был бы другой разговор
SQLAlchemy прекрасный ORM, один из лучших среди всех языков. Но даже на нём написать запрос на пару экранов это будет мучение.
Писал запросы на пару экранов. Не испытал мучения, а наоборот, писал с удовольствием.Как я сказал ранее, алхимия позволяет получить все преимущества императивного подхода (модульность, переиспользование кода и интроспекцию), не потеряв при этом преимуществ сырого SQL
SQLAlchemy прекрасна. Но ее прекрасность обусловлена особенностями Питона, на другом языке такую же красоту не сделать.Можно попробовать изобразить что-то подобное на Kotlin с его DSL, но вряд ли у меня дойдут руки :(
Сейчас, в общем-то, не важно как составлен запрос, если он логически корректен. С ОРМами другие проблемы.
Как раз важно. Есть 100500 способов составить запрос, получив на выходе один и тот же набор данных, но с различными стратегиями вычитывания данных. Производительность может различаться в разы. Например, SQL позволяет поместить подзапрос не только в `FROM`, но и в `SELECT`. Стратегия извлечения данных будет сильно разной
Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан.
> Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан.Святая наивность. Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`. Главный оптимизатор запроса находится перед компом. Оптимизатор БД же тупенький конечный автомат, способный только предварительно вычислить константы, определить мощность множества (cardinality) и выбрать подходящий индекс (или неиспользование индекса -- бывает, так выгоднее).
> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.>Это вы мне говорите, человеку с 20-летним стажем работы с СУБД?
Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами.
А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения.
>> Не похоже, что вы хоть раз писали 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 лет стажа работы с СУБД"
если ты думаешь, что в риал ворлде (с)(тм) кто-то настолько заморачивается, что в одном проекте пишет скуль запросы сразу под разные ДБ (хотя всегда сидят на 1й одновременно), то ты либо
1) не знаешь о чем говоришь
2) не работаешь с запросами сложнее SELECT a_couple_of_columns FROM one_single_table
Возьмём, например, 1С. Несколько мне известно, их продукт работает в реальном мире под разными СУБД, и там запросы сложнее, чем вы написали.
Я работаю в компании, которая разрабатывает продукты (сложные и большие) под разные СУБД.
Насколько мне известно там постгрес.
но вполне может статься что бывает и разное. скорее всего может.только в одной конторе для одного проекта никто не будет расписывать запросы с учетом разницы между СУБД
такой запрос выглядит сложным:
SELECT col1||col2 FROM table
?вроде нет. Однако он может давать совершенно разные результаты на Oracle и сабже, а на других вовсе вызовет ошибку синтаксиса.
ты вот сейчас серьёзно сказал, что люди для себя для своих проектов (или для клиентов, там обычно *всё равно подразумевается что СУБД известна и незаменяема*) сидя на одной СУБД будут писать этот запрос так:
SELECT НЕКАКАЯ_ФУНКЦИЯ_ОПРЕДЕЛЯЮЩАЯ_ВЫПОЛНЯЮЩУЮ_СУБД( есди_оракл то col1||col2, если_пг COALESCE( col1, 0 )||COALESCE( col2, '0' ), если_мускль CONCANT( col1, col2 ), если_голимый col1+col2 ) FROM table
Смотреть в сторону ORB.
зачем? (и что это?)
Object Relational Bridge.
Зачем смотреть? Есть у вас сложный продукт, который однако, легко разбиваются на модули. Можете целиком продавать все модули (крупным денежным клиентам) вместе с Oracle. А можете отдельные модульки с PostgreSQL мелким небогатым. В итоге у вас более полный охват рынка.
Ну если у тебя SQL это тупой Store без хранимых процедур и ты слово профайлер слышишь в первый раз - то тогда да, это не проблема. Купи побольше процов в облаке и всё работать будет.
Это ваше "переносимое и расширяемое", если ему пофиг на транзакционное ядро, которое под ним лежит, скорее всего никакие СУБД вообще не использует.
ИСАМ и реляционные БД с полноценным WAL-ом и MVCC это абсолютно разные вселенные. Если ИСАМ был выбран осознанно, то переводить его на реляционные схемы c MVCC нет никакого смысла -- будет просто тупо медленней и в разы более толсто.
> завязываетесь всегда на специфичные фишкиА варианты? Хотите приведу целый ряд запросов, которые вообще без изменений легко выполняются и в MS SQL и в PostgreSQL, но во втором без модификации уходят в глухой table scan? Обзор тут: https://www.endpoint.com/blog/2020/06/postgresql-improve-gro.../
Я уже молчу о временных и, тем более, глобальных временных таблицах. Тут уже в каждой СУБД свои заморочки, требующие при миграции, нередко, просто переписывания кода.
нооо мооой прооот!
свитый из багов и снов
всем моим бедам назло
вовсе не так уж плох
Оо подошли старперские оптимизации бесконтактного боя
зачем?
Пора тебе побеспокоиться за свой тыл.
> Пора переводить прод с мускула на постгрю!Не стоит. Но стоит задуматься о создании нового прода уже на PostgreSQL. Я не особый спец. Любитель. Но приятно было отказаться от MySQL. Сначала привыкаешь к особенностям. Потом учишься делать хитрые запросы. Потом балуешься с json, которые участвуют в индексах. Потом понимаешь, что для того, чтобы сделать то, что позволяет PostgreSQL на MySQL, мягко говоря, сложно.
Но если ты просто меняешь БД в настройках своей CMS - то это не миграция, а херня. Не стоит. Твой код должен быть написан именно для PostgreSQL с учётом его особенностей. Код не может быть заточен и под MySQL и PostgreSQL. Это компромисс для эникейщиков, чтобы поставить систему на любой сервер.
Слоник - это вещь! Моё уважение проекту.
Надеюсь до постгри раст не доберется!
А было бы неплохо, повышение качества еще никому не вредило
Переписывание затянется в бесконечность.
Посмотрите сколько пунктов в стандарте MISRA. Память лишь один пункт из многих. А понты из закорючек в одну строчку наоборот нежелательно. Для Раста есть подобный стандарт?
Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - значит безопасно. Миллионы растоманов не могут ошибаться.
Зато на Расте синтаксис подталкивает к тому чтобы писать говнокод. А говнокод можно переписывать бесконечно. Это же рай для тех кто любит все переписывать бесконечно!
> Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - значит безопасно. Миллионы растоманов не могут ошибаться.Mozilla, помню, говорила обратное🤔
Посмотрите внимательней на требования MISRA и список тех, кто этой MISR'е следует. Даже ядро линя, а оно существенно более критично чем постгресс, ему не соответствует. А вы про прикладной софт...
> Даже ядро... не соответствуетЭто хорошо или плохо?
С точки зрения надежности - плохо. Но есть мнения что ядро какое оно сейчас вообще невозможно написать с такими ограничениями. Как минимум пришлось бы заставить всех драйверописателей и остальных, чей код тянется в ядро, следовать этим ограничениям. А это нереально.
В этом проекте на С с качеством все в порядке. Давайте не портить его.
rust уже влез в linux. Неплохо бы сначала посмотреть, что из этого получится.
Все давно придумано за вас.И да, есть.
чо за постгри?
Отличный проект. Успехов.
Бредовый синтаксис. У них всегда были с этим проблемы и вот опять.
почему этот нереально жырный и унылый троллинг не удаляется? троллботнумшаблон не заходит?
>Бредовый синтаксис. У них всегда были с этим проблемы и вот опять.у постгреса похоже в штате больше форумных ботов, чем прогеров. :) иначе я просто не понимаю откуда столько минусов у любой критики слонопотамов.
сам пользовался слоном много лет назад, но не понимаю как можно остаться на постгресе хотябы 1 раз пощупав монго ) как жигуль vs нормальная япошка )
> я просто не понимаюМожет быть проблема в тебе, что если ты не прав, не приходило такое в голову?
>Может быть проблема в тебене думаю.
в могучем слоне всё так же - если на диске занято больше 60% то vacuum full уже не сделать? )
Уже обновился на Убунте. Теперь еще численные типы могут содержать значение Infinity.
Мастер-Мастер подвезли? Нет? Тогда сразу в гарбедж.
> Мастер-Мастер подвезли? Нет? Тогда сразу в гарбедж.лол, зочем? он же ничего кроме боли не дает
тебе твой мастер не нравится? слишком белый?
Ему тройничок подавай
>> Повышена эффективность работы индексов B-tree и решена проблема с разрастанием индексов при частом обновлении таблиц.finally
vacuum full надеюсь наконец-то запретили и объявили окончательно и бесповоротно deprecated?А, нет, померещилось...
А смысл?
Нужное. Разрешаю дальнейшую разработку.
А то тут некоторые повадились ненужное без разрешения кодить...
Зачем спрашивать у вас разрешение, вы кто дядя?
Q.E.D.
Хочу opennet но для взрослых. За*был этот десткий сад в комментариях.
А по моему хорошая шутка получилась.
Ещё никто не спрашивал про пакеты и undo?
Подобие пакетов есть. Подобие анду-сегментов тоже есть. Но больше похоже на версионное хранилище МС Сиквела, чем на Оракловую реализацию. Да и не сильно надо, вообще-то. Вот вам анду зачем? Для чего-то вроде флэшбэка по анду?
> В новых установках по умолчанию обеспечено применение парольной аутентификации с использованием метода SCRAM-SHA-256 вместо md5 (параметр "password_encryption" при генерации postgresql.conf теперь устанавливается в значение 'scram-sha-256').Ну наконец-то каждый раз при установке не придётся это ручками изменять, ждал этого давно.
> SELECT * FROM test WHERE details['attributes']['size'] = '"medium"'А чем старый не устроил?
SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'
Фронтендеры пугаются.
> Фронтендеры пугаются.Что фронтендеры вообще в SQL-е забыли, с ним работают только бекеры?
Javascript теперь и на беке давно :-)
Более читабельный.Это уже наркомания какая-то:
SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'
пихать в скуль вот это всё - это и есть наркоманияскуль придуман для относительно простеньких декларативненьких запросиков. ими и должен заниматься.
попытка запихать вселенную в скуль приводит к тому, что у отвёртки из авторемнабора вдруг ручка в виде руля - потому что у машины тоже руль.
Декларативные не равно простенькие. Коррелированные подзапросы с окнами и свёртками сложно назвать простенькими. При этом они крайне немногословны относительно императивных реализаций.
само собой, ибо вся мякотка скрыта в СУБДно они и обычно в хвосте переносимости и самое главное обычно запросы содержащие такое не ограничиваются и малым размером. а это уже всяко плохо. неуправляемо, неподдерживаемо.
если 5 строчный запрос с окном - это неплохо. horses for courses.
> Более читабельный.
> Это уже наркомания какая-то:
> SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'Особенно невозможность разименовать json(b) в которой нужно оборачивать сравниваемую строку в двойные кавычки. который является символом экранирования в pqsql.
Офигенно читаемо!
У этих операторов разный тип результата (-> json, ->> text), а у оператора индексации массива способа поменять тип кроме оборачивания в CAST нет.
Почему же, +- как в php.
> SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'Мне интересно, как эта наркомания вообще пролезла в когда-то человекочитаемый sql
'["a", "b", "c"]'::jsonb ?& array['a', 'b']
'{"a": {"b": ["foo","bar"]}}'::json #>> '{a,b,1}'
Я, если честно, вообще не знаю, зачем до сих пор нужен SQL, если в него приходится пихать все больше и больше фишек обычных языков. Давайте уже оставим SQL в покое, но встроим в него какую-нибудь Джаву, чтобы прямо в запрос скрипт всовывать.
Уже есть встроенные языки plsql, perl, ...
да, это просто традиция что ДБшники как секта всё пихают в свою СУБД и ограничены только её возможностями.раньше СУБД были как отдельная ОС, теперь же и нормальные обычные приложения (на том же Перл или простихоспаде жабе) работают с БД не хуже, благо библиотеки/обвязки нынчо достаточно развиты.
если что-то зело специфическое и аццки оптимизированное надо, тогда да. Но 90%ам это не нужно.
У СУБД свои задачи, у фронтэнда и контроллеров -- свои. Манипулировать данными в десятки раз проще на Сиквеле, а обрабатывать всякие приведения форматов удобнее другими инструментами.
ОРМ в реальных применениях годны только для самых простейших вызовов. И не потому, что делают плохие запросы, а потому, что нет ни одного массового императивного языка, у которого была бы транзакционная модель памяти.
да, но бизлогика на скуле - это неуправляемая messя лично за то чтобы сырые данные с мин обработки хранить в иерархическом виде, а то что нужно крутить, сравнивать, перекрёстно-линковать - это в таблички, где этому и место.
Мне это не нужно,я этого не понимаю. Значит никто не понимает и никому этотне нужно!Дураки какие-то деньги тратят на разработку никому ненужных вещей.
Потому что в Сиквеле двумя фразами можно сделать то, что на императивных языках делается тысячами строк всяких библиотек.
Оракуль пытался, ещё с 90-х. Чё-т не очень жаба SQL или хотя бы PL/SQL заменила
Сиквел ничем не заменить. ПЛ хорошо подружен с Сиквелом. А Ява -- она не для замены ни того, ни другого. Просто на ней можно делать то, что на ПЛ делать затруднительно или реализация получается жутковатая.
Java давно есть https://github.com/tada/pljava
Но заменить SQL она все равно не в состоянии. Парадигма другая.
Зачем все это в SQL DB?
Для функциональности.
Какое отношение имт все эти свистгперделки к функционалу SQL DB?
Чтобы не таскать данные между базой и чем-то ещё по сети туда-сюда
> SELECT ('{ "postgres": { "release": 14 }}'::jsonb)['postgres']['release'];о мама мия... почему эти люди не могут посмотреть как сделано у нормальных людей? у монги апи уже 5 лет назад было разрывающе удобнее подобного бреда....
API на javascript? Как вы себе представляете добавление javascript в SQL?
>SQLэто какое-то гомно из 70-х прошлого века? Зачем за него цепляться?
Да будет тебе известно, что это из 70-х снабжается математическим аппаратом и вообще стройной теорией обработки данных.Где вы такие "прогрессивные" только беретесь-то?
После добавления в монгодб транзакций, постгрес стал официально не нужен.
Монго давно умер. И нет там никаких "транзакций" и быть не может в принципе.
Я аш смузи подавился. Вы все врёте!
С сайта монги: "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.
Хоть сам и сижу на постгре, но рассматриваю ее исключительно как легаси.
На сарае еще и не такое написано, но там - дрова.
чо за постгре?
Афира почитайте, а то может оказаться что транзакции не совсем транзакционны как сейчас.
>Монго давно умер. И нет там никаких "транзакций" и быть не может в принципе.глупый слонопотамщик не понимает, что в монге данные немного по другому хранятся и по существу там были "транзакции" всегда, т.к. в монге не нужно атомарно редактировать по несколько размазанных на несколько таблиц строк ) т.е. атомарность это КОСТЫЛЬ реляционных субд, а не мегафича! )
ну а сейчас и транзакции давно есть, с 4.0 кажись
https://aphyr.com/tags/mongodbТранзакции не имеют никакого отношения к тому как физически хранятся данные, это логическая конструкция и атомарность записи объекта в файл не является достаточной для реализации всех уровней изоляции транзакций.
Причем тут вообще файлы? Монго гарантирует атомарность на уровне документа (или нескольких документов если использовать транзакцию). Физическая реализация может быть какой угодно.
>Транзакции не имеют никакого отношения к тому как физически хранятся данныеТранзакции в 99% случаев не нужны. Либо нужны, но тормозят больше чем нужно...
Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании только. Не поймут твой "прогрессивный" подход.
Ну почему каком-нибудь... Скорее всего в Сбербанке.. Он под себя подомнет весь ИТ в Россиии... :)
>Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании толькоА ты не ляпни про постгрес на собеседовании в банке ))
Иногда стоит промолчать а не демонстрировать уровень своей компетентности
https://www.cnews.ru/news/top/2021-03-23_podderzhivat_za_250...
А вы уверены что транзакций там нет? Может вам просто предоставляют механизм неких гарантий, а под капотом там неявно вызываемые автоматические транзакции как раз и работают?
Респект
Чем PostgresQL 14.0 лучше Firebird 4.0?
Версия больше)Ну але гараж, что за вопросы странные... Чем гугл лучше яндекса и давай отвечай сразу в одном сообщении.. кто так делает..
Не лучше а хуже...
И ответ на этот вопрос вы узнаете сразу же как американский сегмент отключат от интернета...
Вы хотели сказать "российский". С чего бы американцам отключаться от Интернета. Они подобной фигнёй (изоляционизмом) не страдают.
Да и вообще, вон, есть российская контора, которая пилит свою редакцию PostgreSQL.
Есть такой список, "страны угрожающие американскому образу жизни". Это часть доктрины национальной безопасности США. И с каждым годом этот список все все шире... А после строительства Северного Потока- он станет еще шире... С этими странами американские компании не могут торговать, вести отношения...
Так что не исключена ситуация когда США самоизолируется от всего мира... ну кроме ее сателлитов :)
Пока из таких стран - Россия, Китай и КНДР, насколько мне известно. Но, может, я чего не знаю, дополняйте список.
Наверное хорошая штука но ставить не буду никогда тк ее разрабы судя по документации ненавидят заранее всех кто будет ее использовать и всех кто хочет найти примеры)
Очень странный довод. По мне, так у них просто замечательно вылизанная документация - у всех бы так было.
Довольно хреновая у них документация. Архитектура, например, вообще нигде не описана. Приходится с миру по нитке скрести. Да и многие особенности работы тоже нигде не упоминаются.
Так исходный код же есть...
Мало? :)
а когда уже нормальный active/active кластер завезут?
А когда уже direct io, undo нормальный завезут.
