После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 17. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2029 года. Поддержка PostgreSQL 12.x, самой старой из поддерживаемых веток, будет прекращена 14 ноября...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61935
> Добавлена новая утилита pg_createsubscriber для преобразования физической реплики в новую логическую реплику.Годнота! Тут от Postgres Professional
стрим смотрел про это, классно https://www.youtube.com/watch?v=peLXtGorl8A
сначала создали проблему, потому филигранно ее решили? молодцы )))
Корректная ссылка на видео - https://rutube.ru/video/9e2f11226b6c05d70937232c0d17da29/
> При выполнении операции VACUUMмляааааа... в 2009м году они его обещали ОТМЕНИТЬ!
Окончательно и бесповоротно!Кстати, где тот хмырь что год назад обещал нам новый формат хранилища не требующий вакума, уже почти и вот-вот? Убили и съели?
не знаю, какой там хмырь что обещал, но постгрес без вакуума есть:https://github.com/orioledb/orioledb
да, одним extension не обойтись - постгрес всё еще нужно патчить.
скорее это его нет чем есть -Commits on Sep 26, 2024
feature: Lock S3 bucket on startup (#371)
za-arthur committed Sep 26, 2024Commits on Sep 18, 2024
Use yapf to format root folder python scripts
akorotkov committed Sep 18, 2024Update copyright
akorotkov committed Sep 18, 2024Commits on Jul 21, 2024
работа, как видим, кипитЪ!
А статус по прежнему - "пригодно для экспериментов". Год уже прошел, или больше?
Ну, как proof of concept есть.А то, что никто на это время не дал ему денег на "допилить" - тут одно из двух: либо он не смог никому, у кого есть деньги, объяснить пользу, либо это никому не надо.
Есть ещё один вариант, наиболее вероятный: денег нет и не будет. Сами едва живы.
С таким флагом из всех щелей он деняг и не получит.
Недавно тестировал на нагрузках. Еще сырое, после определенного кол-ва активных инсертов начинаются утечки памяти и все падает.
Так ведь вакуум - это следствие того, что сама БД - версионка.
И оперирует версиями строк, что как бы еще в самом начале рассказывают.
Как бы в 21 веке оперировать версиями строи и потом запускать вакуум некошерно. Не неходите? Это же не 70-е годы того века. Почти 50 лет от тех времен прошло.ПС. Оакловый подход, в общем, тоже немного устарел, но более комфортен при промышленной эксплуатации
> Как бы в 21 веке оперировать версиями строи и потом запускать вакуум некошерно. Не неходите? Это же не 70-е годы того века. Почти 50 лет от тех времен прошло.Какая разница сколько прошло и какой сейчас век. Байтам больше 50 лет, так что, ими некошерно пользоваться? Возвращаясь к вакууму - что, придумали что-то лучше? Только не говори что undo логи писать которые то же самое, только наоборот, при этом сложнее и медленнее.
> Возвращаясь к вакууму - что, придумали что-то лучше? Только не говори что undo логи писать которые то же самое, только наоборот, при этом сложнее и медленнее.Не то же самое, всё же. Там этим vacuum-ом не надо заниматься, всё автоматически делается. И это, вакуум быстрый, что ли? Да не смеши мои тапки. Кроме того, ты, очевидно, этого не знаешь. Но undo можно положить на другую дисковую подсистему. А с vacuum-ом ты приплыл, никак не масштабируется, потому что in-place.
К сожалению подросло поколение людей, которые не только не знают и не хотят ничего знать, но и гордятся своим незнанием - примерно как в фильме "Идиократия". И ваше объяснение - это как метать бисер перед нечистоплотными животными, может быть. Хорошо если это будет не так, и они пойдут, найдут информацию, попробуют ее понять, и сделают для себя какие-то полезные выводы.
Специфика работы MVCC в Оракле сложна и запутана. Вникать в её тонкости практически нет никакого смысла, потому что процесс этот для настройки почти не доступен, да и от версии к версии меняется (хотя с 11-той версии, вроде как, не особо). Знают её единицы, и то по случайности. Вот я один из таких единиц. Выносить UNDO с другую точку монтирования штука полезная, но и в случае Слона проблема с вв имеет свои решения, но уже на уровне ОС или оборудования, а не на уровне СУБД. Слон вообще полуфабрикат, его не стоит сравнивать с готовыми коммерческими продуктами. На базе Слона можно сделать вполне годную СУБД под свои задачи, главное не пытаться подходить к этому со стереотипами, выработанными при работе с Майком или Ораклом.
Вакуум быстрый, да. Не помню уже с какой версии стало сильно быстрее, по-моему, с 13 или 14-той. Главное под автовакуум места не жалеть.
Места в смысле оперативы.
Вижу знатока. Чем же подход Оракла отличается от того, что используется в Postgres? Ну-ка, ну-ка. Открываю большую пачку с чипсами.
Там нет vacuum. Видимо, этим. А что же там есть? Там есть отдельное табличное пространство для целей сохранения предыдущих значений (до начала транзакции). Недостатки: для длинной транзакции rollback может длиться очень долго (столько же, сколько изменение данных во время транзакции). Достоинства - откаты данных происходят сравнительно редко, поэтому нет необходимости постоянно делать vacuum.
Это как если житель, скажем, рязанской области, зайдя в магаз где-нибудь где-нибудь в Станбуле, не нашёл бы там товара с названием Хлеб и заявил, что турки хлеба не едят.
Оракл тоже хранит хронологические данные. Да, в отдельном ТП, но данные туда надо перемещать, это дополнительные затраты, к тому же Оракл хранит там чаще всего не целые строки, а дифы и директивы отмены, что сильно экономит место, если изменение небольшое, а строка большая, но делает процесс построения актуального значения блока для запросившей транзакции делом довольно затратным. Затратным относительно Слона, у которого хронологические данные никак от "живых" не отличаются и доступны сразу там же. И точно так же надо в Оракле следить за размером UNDO. Ну и ты сам в чатгпт вычитал, что подход Оракла тормозит в случае отката. Прям, сильно тормозит. Вряд ли ты знаешь почему. А вот утверждение, что транзакции куда чаще завершаются фиксацией, чем откатом, это, мягко говоря, очень сильное допущение.
В общем, mvcc это всегда необходимость хранить хронологические данные и всегда необходимость строить из этих данных блоки под конкретную транзакцию. Реализаций есть множество и какой-то волшебной превосходящей всех и вся до сих пор нет.
>Ну и ты сам в чатгпт вычитал, что подход Оракла тормозит в случае отката. Прям, сильно тормозит. Вряд ли ты знаешь почему.Столько глупых предположений в одном сообщении... Нет, я вычитал всё это из документации, а не чатжпт. Потому что приходилось иметь дело с обеими СУБД на практике в течение многих лет (особенно с Ораклом, с Постгре всего года два, да и то только в разработке). Тормозит потому, что данные из Undo копируются назад. Но ещё раз, Undo можно положить на другую дисковую систему, в отличие от.
>А вот утверждение, что транзакции куда чаще завершаются фиксацией, чем откатом, это, мягко говоря, очень сильное допущение.
Правда, что ли? Предлагаю подумать головой более тщательно, прежде чем писать подобное.
Специфики работы UNDO в документации нет вообще, она там не нужна. Как нет и ничего про внутренние процессы сервера. Медийных материалов по этой теме, кроме одной единственной книжки Льюиса начала 10-х, тоже нет. Поэтому и чатгпт.
Тормозит не потому, что что-то там "копируется назад" (и что это за "назад" такой???). Хотя, ещё раз, это не важно особо.
эта одна из первых вещей, которые рассказывают тем же (будущим) админам ПГа потом ещё про "переполнение" какого-то счётчика.
погоди, они и это не смогли починить?! Про "переполнение" мне тоже рассказывали... давным-давно со словами "ну вот щас-щас щас решим и эту проблему".
Мне рассказывал толковый тыЮтор, возможно поэтому про щастамвсёпочинят он не говорил. Просто рассказал, что это и почему. В т.ч. что совсем уж просто не починится.Впрочем, курс он читал всем известный от ПРОшников.
ЗЫ и да, я без понятия, может и "починили". Я не ДБА, поэтому после уже не интересовался.ЗЗЫ ЕМНИП переход на 64 бита должен был сделать число уже совсем неприлично большим.
Вам бы на компьютерные курсы сходить чтоль, более безграмотных постов про постгрес я тут не видел
Закрой глазки.
> ЗЫ и да, я без понятия, может и "починили". Я не ДБА,не надейся, у меня "настоящие" dba через стол сидят, мы как раз надысь ржали по этому поводу.
> ЗЗЫ ЕМНИП переход на 64 бита должен был сделать число уже совсем
А енто только в про. Покупайте наших слонов!
А ты думаешь они там просто так сидят на зарплате?
> А ты думаешь они там просто так сидят на зарплате?ну могли бы книжки писать...оh..shi...
Так твой дба тоже безграмотный и все время ржёт с того случая как ему на стройке кирпич на голову упал.
Да и был бы он грамотным не был бы дба.
У вас программисты рулят базами данных? Тады ой, беда, печаль. Мне вас искренне жаль, в общем.
Типа, ты сейчас мне преподал урок логики? Раз грамотен, значит - программист, ну а если безграмотен - DBA? 🤣
А что безграмотного этот DBA сказал-то? Всё ж в доке написано. Разве нет? Счётчик идёт по кругу. Для тех случаев, когда базок в кластере много (например, для целей разработки под разных клиентов, разные версии софта) - это может стать проблемой. Понятно, что в проде столкнуться с этим сложнее. Но всё же нельзя вот так вот просто закрыть глаза на эту проблему, которая не решается уже сколько лет?
Зато можно поржать.
Не, ну надо же хорошим людям на чем-то зарабатывать? Вот, одна из первых продавашек астровского tantor'а:
"64-битный счетчик транзакций(XID)
В PostgreSQL существует ограничение (N = 232) на количество идентификаторов транзакций (XID), при достижении которого необходимо выполнить процедуру заморозки. С 64-битным XID переполнение счетчика транзакций становится фактически невозможным"
покупайте-наших-слонов!
А зачем этот 64-битный счётчик? Чтоб было? В практике никогда не встречал, чтобы 32-битный счётчик становился проблемой. Ну, красиво, конечно, когда он 64-битный -- тогда можно подзабить на вакуум, но если вакуум адекватно настроен, то счётчик никогда не становится проблемой.
> А зачем этот 64-битный счётчик? Чтоб было? В практике никогда не встречал,
> чтобы 32-битный счётчик становился проблемой. Ну, красиво, конечно, когда он 64-битный
> -- тогда можно подзабить на вакуум, но если вакуум адекватно настроен,
> то счётчик никогда не становится проблемой.Ужтыж! Аноним не встречал - и впрямь не за чем. Пойду напишу в postgres pro\tantor labs, пусть откатывают и за консультацией по настройке вакуума на опенок идут.
Моркентинг. 32 больше 64? Больше. Значит, лучше. Ты сам себе попробуй объяснить чем в твоём конкретном случае 32-битный счётчик будет ограничением. Если Postgres использовать, как Postgres, т.е. одна целевая БД на экземпляр, а не как Майк или "мультиарендные" версии Оракла, то 32-битного счётчика за глаза. Проблема 64-тного надуманная полностью, т.е. обычно, если экземпляр фризится из-за исчерпания счётчика, то у него и так уже масса проблем. Из-за криво настроенного вакуума, да. Ну или из-за того, что на один экземпляр навешали кучу БД с кучей транзакций.
У мёрзлого ежика зачем 64-битный счётчик более-менее понятно -- у них лицензия за ЭКЗЕМПЛЯР и кол-во процов. Поэтому экземпляр под каждую БД не поподнимаешь. Если на один экземпляр несколько БД (что для Слона крайне не рекомендуется, да и для Майков тоже так делать не надо), то 32-битный счётчик это печаль, да.
> У мёрзлого ежика зачем 64-битный счётчик более-менее понятно -- у них лицензия
> за ЭКЗЕМПЛЯР и кол-во процов. Поэтому экземпляр под каждую БД не
> поподнимаешь. Если на один экземпляр несколько БД (что для Слона крайне
> не рекомендуется, да и для Майков тоже так делать не надо),
> то 32-битный счётчик это печаль, да.Не, ну если ресурсов на каждый микросервис в каждой из сред по кластеру поднять не жалко - то можно и так, да...
Postgres для микросервисов не вариант вообще. Там лайта за глаза. Если вообще нужно в реляционной схеме с данным работать. Но микросервисы это нелепое дно.
> Postgres для микросервисов не вариант вообще. Там лайта за глаза. Если вообще
> нужно в реляционной схеме с данным работать. Но микросервисы это нелепое
> дно.Ну, если Вы так говорите...
64-разрядный счетчик хотя бы для того, чтобы на репликации у тебя вдруг колом не встал мастер, потому что реплика по какой-то причине отстала.
Т.е. у тебя есть слот, реплика отвалилась на полгода, а потом, через полгода, ты решил наверстать упущенное? Ну, ок, если у тебя очень-очень много места на архив вала на это время, то что-то рациональное в этом можно усмотреть.
Но это же не непреодолимая проблема -- можно же настроить игнорирование слота в таких ситуациях, чтоб мастер не затупил. Хотя, ещё раз, моего воображения не хватает представить себе однобазовый экземпляр с таким кол-вом транзакций, что реплика в типичных условиях применения упиралась в счётчик.
Не знаю кто тебе что там обещал, но MVCC с вакуумом на данный момент не имеет аналогов по проиводительности.
Ну уж так мёдом лить не надо. Реализация обслуживания mvcc в Слоне не сравнимо хуже, чем в Оракле, и, в общем, хуже, чем у Майков, но вполне себе съедобно.
Ну, ок, уточню -- хуже для случаев, когда транзакция COMMIT-ом завершается, но лучше, когда ROLLBACK-ом. Это если только производительность именно данной конкретной функциональности в отрыве от прочих накладных расходов рассматривать. Всё же сохранять хронологические данные вместе в оперативными прикладными хоть и быстро, но уж очень имеет тенденцию пухнуть. Даже если вакуум адекватный, но всё равно оракловые UNDO и майковое VERSION STORE в TempDB лучше. На мой взгляд. Но и решением Слона вполне можно жить.
Rollback намного более редкая ситуация на практике, чем Commit.
нах, тебе-то чем вакуум не угодил?
Тем, что это убогая технология, которая может (не обязательно, но случаев много) повлечь за собой кучу проблем. Сейчас, конечно, с ним получше стало, чем N лет назад. Но всё равно, любой commit - это тормоза по определению из-за вот этого способа сохранять старые данные. Плюс отсутствие масштабирования. У Oracle UNDO можно положить на другую дисковую подсистему. С PG так не получится, разве что отдельные таблицы раскидывать по этим подсистемам. Плюс таблицы регулярно пухнут. И получается, для часто изменяемых таблиц без vacuum - никак. Особенно, если эти таблицы в отчётности какой ещё участвуют. Ведь не почистишь таблицу, придётся (если полное сканирование) перелопачивать все данные, в том числе старые, которые уже никому не нужны ни в каком виде.
Никаких тормозов фиксация в Слоне не подразумевает. В Слоне фиксация очень простая операция. С остальным, скорее, согласен. Файлы данных в Слоне пухнут, да. Пухнут даже при нормально настроенном вакууме. До сих пор нет онлайнового полного вакуума. И это реальная, а не надуманная проблема.
Разумеется, сам по себе commit - быстрая операция. Но подготовка к нему, особенно, когда данных меняется много и разнести ввод-вывод (в отличие от Оракла) никак нельзя, потому что всё in-place...
Ну почему нельзя-то? Расслоить вв ничто не мешает. И у Слона нет изменений инплэйс никогда, кроме тостов. Это со временем и становится проблемой.
>До сих пор нет онлайнового полного вакуума. И это реальная, а не надуманная проблема.Есть, но через расширение.
https://reorg.github.io/pg_repack/
Костыльно, всрато, но работает.
UNOD пока не завезли, тогда пофиг будем на любом postgresql
>в течение пяти летВот интересно как тут влияет длительность поддержки.
Рейтинг популярности СУБД:
https://db-engines.com/en/ranking
"their popularity"What is it? Next bullshit?
Почему МарияДБ сползла в подвал?
Потому как время форумов и баз для сайтов прошло.
Фанатики форсили, но на практике мускл намного более полноценный продукт.
На практике одно и то же. И нет смысла переходить на Марию.
На практике, Мария хуже Мускуля!
Так как есть в ней моменты, которые после форка в мускуле исправили а в Марие до сих пор нет.
И JSON через жопу в ней реализовали.Если у вас типичный сайт на вордпрессе или другой CMS или сайт на каком-нибудь фреймвёрке с моделью PDO, то разницы, практически не будет.
Но если вы инженер и вы разрабатываете сложную структуру, которая будет завязана на СУБД,
и вы сравниваете различия между ними, то результат выбора очевиден в пользу MySQL.
... то результат выбора очевиден в пользу PostgreSQLИсправил, не благодари!(С)
> ... то результат выбора очевиден в пользу PostgreSQL
> Исправил, не благодари!(С)Да не за что, могу и постгресс разобрать!
1 Постгрессчики часто хвалятся поисковой системой.
У MySQL InnoDB тоже есть полнотекстовый поиск, который даже проще в использовании и вполне годен для простого использования (нагрузка на поиск не большая).
Если же нужен поиск с большой нагрузкой, то MySQL+Shinx уделывает его.2 Постгрессу c кучей разных типов полей неводом тип unsigned (tiny,small,medium)int.
А типы tinyint и mediumint вовсе не ведомы!
То есть если мне нужно битовое поле, то на каждое придётся выделять 2 байта вместо 1!
Сохранить компактно unix timestamp и crs32 в 4 байтах в unsigned int не получится, ведь его там нет! Используй 8 бит вместо 4!3 Жрать память постгрес любит, просо обожает!
На проекте БД в несколько ТБ и вышла свежая версия 17, здорово было бы обновится?
На MySQL это не составит никакого труда, ну естественно бекапы никто не отменял, там миграция данных к новой версии или вообще не нужна или выполняется быстро и автоматически!
А вот постгресс БД в несколько ТБ ты не обновишь, они НЕ совместимы между версий!
Ты должен сделать именно текстовый бэкап, так как физическая репликация и бинарный бэкап НЕ совместимы между разных версий!
И или ты вечно должен быть на старой версии или использовать только текстовый логический бэкап, который будет весить уже десятки Тэр каждый!
И перейти на свежую версию практически невозможно! Так как очень долго, трудно, и высока вероятность накосячить из-за сетевого сбоя! В MySQL такой проблемы нет и никогда не было!4 Сама идея версионности, в которой ты изменяешь данные, и старые не перестают существовать, как в MySQL, а создаётся копия данных, которая существует паралельно с новой, и при каких-то обстоятельствах может быть даже прочитана, и нужен запуск вакуума чтобы, её очистить, просто кажется каким-то безумием!
5 У MySQL каждый тип поля строго ограничен! Это позволяет как более эффективно использовать место, так и разработчика задумываться о выделении максимального размера под данные и их проверку и валидацию!
У постгресса же есть очень распространённый тип text, который ограничен только файловой системой и я видел много кода, в котором вообще проверки на размер данных нету они всё что пришло в посте от пользователя тупо помещают в поля с типом text без каких-либо проверок!6 У MySQL есть несколько движков, в особенности MyISAM, скорость вставки в который в 16 раз выше, чем в постгресс и InnoDB!
Была у меня задача по аналитике, где каждый раз по запросу аналитика нужно обработать данные от огромных нескольких таблиц с предложениями и спросами и сформировать результирующую таблицу в удочитаемом формате. На MySQL MyISAM мой код выполнялся в 16 раз быстрее, чем написанный на постгрессе!7 Ну и ещё мелочь вспомнил, когда я модифицирую таблицу в MySQL я могу добавить новое поле в любое место таблицы, хоть в самое начало, но в постгрессе я могу добавить поле лишь в самый конец!
Из всего изложенного я давно понял, что в типичных web-приложениях с одним основным пользователем БД, MySQL лучший выбор!
Он быстрее, гибчеб эффективнее, надёжнее и легче в ослуживании!
Хорошее подтверждение пословицы про меньше знаешь, лучше спишь. Если на твоём уровне восприятия, то Инно очень мало, чем отличается от Слона. В бесплатном, т.е. самой массовом, виде в Инно намерено и предупреждая об этом забили на ряд проблем с надёжностью сохранения данных в случаях аварийного сбоя экземпляра, в Слоне с этим проблемы нет. MyISAM это вообще не СУБД, а просто ненадёжная строковая хранилка (чтобы ты понял что-то вроде эксэльки), поэтому и быстрая, потому что целостность данных никак не обеспечивается вообще. Когда понимаешь, что к чему, этот баг может быть и фичей (например, при регистрации не слишком ценных данных, когда некоторые потери допустимы), но ты всё равно не понимаешь, поэтому просто рискуешь потерять данные...
Не знаю, как мария, в РФ на мой взгляд в основном набирает популярность postgresqlмне во многих компаниях говорили, что они отказываются от mssql или oracle, и двигаются в сторону postgres
В тех компаниях, что я работал, как сидели так и сидят на mssql. И двигаться там куда-то они не собираются по причине - руководство эти ваши постгресукеелы не знает и знать не велит.
"Заставляют отказываться" ...
И таки да - пытаются заменить ... Но замена неравнозначная ... Не знаю про Oracle - но при замене MS SQL скорость деградирует в разы.
Причём, если для 1с ЗУиП скорость хоть как-то довели до приемлемого уровня, то для крупняка, типа адванты, нет.
Там проблема в 1С, а не в СУБД. Изначально пилили под блокировщик и грязное чтение, поэтому теперь и проблемы с Postgres, в котором грязного чтения нет в принципе.
> Но замена неравнозначнаяВот заиспользуют все самые специфичные мутные фичи от БД, а потом за голову хватаются.
Оракл и Майк не купить.
> Рейтинг популярности СУБДЧто там делает монго?
>Что там делает монго?ворочает терабайтами ) причём уж побыстрее кое-кого, не будем пальцами показывать.
Это та сама монга которая не в состоянии сделать самый примитивный джоин? Такая база только для смузиков.
>>Что там делает монго?
> ворочает терабайтами ) причём уж побыстрее кое-кого, не будем пальцами показывать.нуууу фффцелом... зашифровать нафиг всю тазу банных какого-нибудь особо модного-современного-облачного ентер-прайса у нее действительно сильно побыстрее многих выходило.
(подскажите, эксперты - у нее по прежнему дефолтная конфигурация без авторизации вовсе, да?)
По умолчанию вход только с локалхоста без авторизации.
> По умолчанию вход только с локалхоста без авторизации.и кому оно нужно такое умолчание? К тому же это скорее всего - настройка твоего дистрибутива, чтоб ты пое...лся лишний раз.
Я с сайта ставил по официальной доке https://www.mongodb.com/docs/manual/tutorial/install-mongodb.../
Давно сдохла. Его крупняк везде выпиливает. С огромным трудом и затратами.
R:Base приподнялся ...
Ах - где мои 17 лет и красный сарафан ?
>Расширены возможности SQL-команды "MERGE", позволяющей создавать условные SQL-выражения, объединяющие в одном выражении операции INSERT, UPDATE и DELETE.Вау, изобрели то что было было в монге 2.х 10 лет назад.
Не изобрели, а пробили и протащили в релиз.
Теме почти 20 лет )
https://habr.com/ru/companies/postgrespro/articles/412605/
>Реализована поддержка новых возможностей для работы с форматом JSON, определённых в стандарте SQL/JSONSQL/JSON - это тупиковый путь, натягивать JSON в SQL. Посмотрели бы как в монге сделана работа с JSON - очень удобно.
> SQL/JSON - это тупиковый путьнет, попробуй поработать в реальных большию компаниях, увиденное тебя удивит
Работал я в одной компании так там золотым микроскопом шурупы забивают в бетонную стену. Увиденного хватило.
>попробуй поработать в реальных большию компаниях, увиденное тебя удивитда я в курсе, переходят на 1С и поц^WТантор ) мне хорошо в маленькой компании, где я сам себе техлид )
>попробуй поработать в реальных большию компанияха ещё натягивают на свой любимый SQL всякие уродства типа Hibernate или JUKE, чтобы поменьше тошнило. А просто взять изначально объектную СУБД дядя-насяльника не велит )
Начнём с того, что в огромной куче задач тебе вообще не нужна субд.
А продолжим тем, что в другой огромной куче нужна.
Поэтому для этих задач мы напишешь хранимых процедур и будем их поддерживать.
Для каждого болта свой молоток.
Где-то нужна объектная СУБД, а где-то и ClickHouse самое оптимальное.
Их нет, "объектных" СУБД. На рынке только реляционные остались. Остальное -- не нужно.
Есть. Oracle.
Нет, Оракл ни разу не объектная СУБД.
Лень искать их рекламные проспекты N-летней давности.
Объектных СУБД не существует в природе. Рабочих.
А что, MUMPS и его наследник Cache сдохли ?
И что там было у межделмаша в AS/400 ?
Это не "Объектные СУБД", а в нынешнем понимании что-то вроде Ф/С с COW. Ну вот какой-нибудь ZFS. Только с исходно аппаратными подходами к обеспечению надёжности сохранения данных. "Объектных" СУБД не существует не потому что я этого не хочу признавать, а потому что это не пойми что, т.е. нет набора критериев, которые бы позволяли сказать, что вот это вот перед нами объектная СУБД, а не фиг пойми что. Вот есть куда более понятный пример той же Монги или хранения ясончиков в блобах. Но то, что там неким образом сериализованные "объекты" хранятся не делает хранилку СУБД, потому что единообразно манипулировать информацией этих объектов возможности нет. Да и что такое -- объект? Классическое определение это экземпляр типа, т.е. нечто материализованное в памяти. Но для, скажем, Джавы это будет одно, а вот для JS -- совсем-совсем другое. Нет единого определения нет и теории со счислением. А для реляционки -- есть. И отображение объектов в реляционку проблема исключительно надуманная.
Oracle. Вполне себе объектная СУБД по совместительству. Рабочая.
В каждую радужную ветку про постгре надо заносить ссылки примерно такие
https://www.linux.org.ru/news/opensource/17209306?cid=17209869
и дальше по обсуждению.
Эту ветку https://www.linux.org.ru/news/proprietary/17234705#comments
Что-то такое https://www.linux.org.ru/news/opensource/17652488?cid=17652756
И просто поискать по всему лор. Тут то очки и спадут.
Будет ли в новой версии работать такой запрос?SELECT file AS b FROM files ORDER BY SUBSTR(b, 6);
В 15 не работает.
Со Слоном работаю с 9-той версии. И такое всегда работало. И сейчас прекрасно работает.