Postgres Professional на втором месте в мировом рейтинге разработчиков PostgreSQL

Покажите мне бесплатный аналог ms visual stusio for ms sql для постгреса?

https://www.dbvis.com

Это я прекрасно знаю - долгое время работал на рынке ККТ и пр. с ним связанного, но какой вклад ихние «что-то пошло не так» внесли в постгресс?

pgadmin, dbbeaver и что угодно

Давно так не смеялся :)

И чем же так сильно MySQL проще к примеру PostgreSQL?

Я говорил не о mysql, я говорил о всяких вордпрессах.

Тем, что MySQL колхозный?

разумеется.

Полноценная совместимость с MySQL сделала бы PostgreSQL еще популярнее за счет перехода админов, которые брезгливо относятся к MySQL.

«админы» далеко не всегда определяют выбор ПО.

Да смейся че… Я вообще через psql к базе подключаюсь

Покажите мне бесплатный аналог ms visual stusio for ms sql для постгреса?

https://www.dbvis.com

И? Там весь практический функционал - за деньги. А бесплатная версия и рядом не валялась с msvs for mssql

Да смейся че… Я вообще через psql к базе подключаюсь

«Рад за тебя» (с)

Покажите мне бесплатный аналог ms visual stusio for ms sql для постгреса?

А вы какой-то странный юморист - пытаетесь сравнивать сильно платные продукты с бесплатными. Вам самому не смешно?

Сейчас Microsoft получит от российских организаций ответы на ее запросы, что наши, российские фирмы, не планируют в будущем пользоваться продукцией этой фирмы. И Microsoft в своих новых продуктах и новых патчах к текущим продуктам сделает так, что все ваши «не лицензионные» и даже «лицензионные» продукты перестанут работать или начнут сливать информацию о ваших данных организациям «розовых пони, какающих бабочками» - АНБ, ЦРУ, ФБР и другим, имя которым - Легион. Вам такая мысль не приходила в головушку? В то же время Postgres и средства разработки для нее можно собрать из исходников, которые можно проверить и верифицировать и у нас в России такой опыт есть.

Там весь практический функционал - за деньги.

Чего именно не хватает в бесплатной версии по сравнению с MSSQL Studio?

начнут сливать информацию о ваших данных организациям «розовых пони, какающих бабочками» - АНБ, ЦРУ, ФБР и другим, имя которым - Легион.

А раньше они этого не делали ? LOL

«админы» далеко не всегда определяют выбор ПО.

Подразумевались в т.ч. старшие, начальники - админы и т.п.

Я говорил не о mysql, я говорил о всяких вордпрессах.

Однако в контексте следующего:

Я понятия не имею сколько там времени кто пытается засунуть в вп постгресс, но раз за столько времени этого не произошло, значит уже и пытаться не стоит, ибо в реальности не нужно.

Т.е. речь о том, что популярные CMSки наглухо прибиты к диалекту MySQL.

Я предложил эффективный способ, как их отучить от MySQL и приучить к PostgreSQL без единого изменения в их коде все и сразу. С помощью realtime транслятора с диалекта MySQL на PostgreSQL.

Я предложил эффективный способ, как их отучить от MySQL и приучить к PostgreSQL без единого изменения в их коде все и сразу. С помощью realtime транслятора с диалекта MySQL на PostgreSQL.

Костыль ты предложил.

Чего именно не хватает в бесплатной версии по сравнению с MSSQL Studio?

Table management - нету

Procedure, function, package and trigger - нету

Database scheduling, events, jobs - нету

Это - вообще эпично :)

Table data viewer/Editor - нету

Table import & export - нету

Query builder - нету

Client-side commands - нету

Explain plan - нету

Charts - нету

Command line interface - нету :)

Костыль ты предложил.

И чем же он плох для легких CMS ? Разве плохо было бы заменить масикуель на что-нибудь нормальное типа PostgreSQL одним взмахом волшебной палочки? А не огромными затратами на переписывание всех этих CMS?

Так переводили даже серьезные системы (а не бесплатные CMSки) с Oracle на IBM Db2 за счет наличия в Db2 подобного как ты выразился «костыля».

Хм, видимо у меня был evaluation период DbViz.

Сейчас уже многие функции поотключались :(

а что с ними не так? по пунктам, пожалста, а то они перекрывают 100% моих потребностей и я никогда проблем с ними не ощущал. если хотите из коммерческих продуктов как студия у мс, то есть datagrip. но вообще я 99% всех операций делаю из консоли и такие инструменты мне просто не нужны.

я вот все слышу какой мускул маленький и юркий, подходит для маленьких проектов и вообще весь такой маленький. просто давайте цифрами покидаемся. я поднял в докере мускул и пг, проинициализировал каждую субд 1 пустой базой и сделал docker stats

итого что мы имеем

```
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
cd6ecd954a9b postgres 0.00% 30.47MiB / 31.29GiB 0.10% 3.49kB / 0B 4.1kB / 40.9MB 6
f6cddcae559d mysql 0.01% 79.59MiB / 31.29GiB 0.25% 2.67kB / 0B 9.73MB / 47.1MB 8
```

имеем мы то, что все ваши утверждения про мускул на снеге писены, пг лучше по памяти и производительнее, отлично подходит как для маленьких проектов, так и для огромных благодаря огромным возможностям для кластеризации и шардированию. у мускула же все это делается костылями, скотчем и надеждой что индексы не разнесет (а это происходит с завидной регулярностью когда память у мускула течет и заставляет его раз в месяц падать). да блин, мускул даже в простое потребляет цпу! а по памяти более, чем в 2 раза жирнее.

когда я ушел с мускула на пг я понял какое же гуано я пользовал и как ошибался и что будущее за пг каким бы проект не был, большим или маленьким.

Вот тебе еще пример. 1С. Знаешь в пользу чего произойдет выбор в небольшой компании, в случае, если используется sql-версия 1с?

Справедливости ради - поставить postgresql в 1с редакции и запустить все сейчас даже проще чем с mssql. Что-то, а вот первичная настройка у баз ms всегда через одно место была сделана.

PgSQL топчик, а контура дниЩе.

вообще пофиг на эти дата-базы, они могут все настройки своих cms держать в .txt файле, но нет они придумывают такое и обсуждают какое ненужно лучше.

вообще пофиг на эти дата-базы, они могут все настройки своих cms держать в .txt файле, но нет они придумывают такое и обсуждают какое ненужно лучше.

Можно пример более или менее сложной и функциональной CMS без БД, которая сможет составить конкуренцию хотя бы для WordPress?

пользовался только drupal, оно требует БД, но я речь веду про то что можно же было создать например drupal который не требует БД.

что там по инсертам после нескольких миллионов записей? пофиксили уже или «вы неправильно используете бд»?

Вот тебе еще пример. 1С. Знаешь в пользу чего произойдет выбор в небольшой компании, в случае, если используется sql-версия 1с? Если компания небольшая, то, с вероятностью процентов в 80 это будет mssql express, потом последует полноценный mssql, а вот постгресс будет выбран только в случае, если мы будет крутить базы под линуксом. И то - до определенного объема.

Перепутаны места у постгрес и mssql express. Постгрес ставят по умолчанию, если нет СУБД, потому что он скачивается сразу с сайта 1С и ставят всегда, если пришлось поставить мини-сервер из-за ограничения размера файловых баз 1С. MSSQL ставят если он уже есть для чего-то или у сисадмина уже есть пиратский. MSSQL express ставят только если сисадмин умеет только MSSQL и нет денег на лицензию и пиратское ставить нельзя.

И то - до определенного объема.

Это до какого? Сотню гигабайт постгрес крутит без проблем. И на что меняют под линуксом?

Перепутаны места у постгрес и mssql express. Постгрес ставят по умолчанию, если нет СУБД, потому что он скачивается сразу с сайта 1С и ставят всегда, если пришлось поставить мини-сервер из-за ограничения размера файловых баз 1С. MSSQL ставят если он уже есть для чего-то или у сисадмина уже есть пиратский. MSSQL express ставят только если сисадмин умеет только MSSQL и нет денег на лицензию и пиратское ставить нельзя.

Нет - не перепутаны. Потому как в небольших компаниях именно «сисадмин умеет только MSSQL». Вы слишком хорошего мнения о состоянии дел в небольших компаниях и квалификации нынешнего персонала. Так сказать - по себе судите. К сожалению, в подавляющем большинстве случаев, это - не так.

Сужу примерно по 30 организациям. В небольших компаниях сисадмин даже мсскьюэль не знает. На 5 постгресов один экспресс. Там, где файловые и возможен переход на сервер, наверняка тоже постгрес выбрали бы.

В нём всё продумано и сделано для людей

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

что добрая половина заявленных фич попросту не работает

Какие фичи не работают? Можно 1-2 примера, пожалуйста.

складывается впечатление, что общий подход к разработке можно описать примерно так: если у вас что-то не работает, то значит вы неправильно используете нашу распрекрасную СУБД.

Периодически читаю рассылки Postgres, ни разу за всё время такого не видел.

ну давайте, для примера, поговорим о фиче, от которой местные любители опенсорса активно тащились после выхода 11 версии - секционирование таблиц. Оказывается толку от этого секционирования в постгресе нет никакого (ну разве что организовывать помойные таблицы для хранения логов, хотя для этого существуют более подходящие решения) - глобальных индексов оно не умеет (https://www.highgo.ca/2022/10/14/global-index-a-different-approach/) со всеми вытекающими: оптимизатор смотрит на это эти секции как баран на новые ворота, т.е. в контексте скорости выполнения запросов оно от «секций на представлениях» совсем никуда не ушло. А теперь давайте посмотрим как на эту проблему смотрят представители core team (https://www.postgresql.org/message-id/19464.1572444806%40sss.pgh.pa.us):

I believe that the current design of partitioning is explicitly intended to avoid the need for such a construct. It’d be absolutely disastrous to have such a thing from many standpoints, including the breadth of locking needed to work with the global index, the difficulty of vacuuming, and the impossibility of cheaply attaching or detaching partitions.

In other words, this is a «feature» we do not want.

Здесь нужно понимать, что если даже вас вежливо послали куда подальше, то вас все равно послали.

Секционирование таблиц существовало задолго до выхода 11 версии. Просто начиная с какой-то версии стало требоваться меньше ручных телодвижений, чтобы его завести.

По поводу глобального индекса, к сожалению, не могу навскидку ничего сказать, кроме того, что мне кажется, что секционирование — вообще очень ограниченный механизм.

Честно не раз пытался придумать применение секционированию (кроме очевидного подхода с логами) и смог эффективно применить только однажды, в очень специфичной ситуации, которая не встретится в 99% проектов.

При этом исключение секций по ключу секционирования надёжно работает уже много лет, проверено.

Ну и разработчики Postgres не скрывают ничего в документации, то есть, нет такого, чтобы в документации было заявлено про глобальный индекс, а в реальности его нет или он не работает.

Ну и разработчики Postgres не скрывают ничего в документации, то есть, нет такого, чтобы в документации было заявлено про глобальный индекс, а в реальности его нет или он не работает.

я в документации как-то не смог найти утверждения, что фича абсолютно бесполезна и не стоит ее использовать. К слову, в документации также нет текста из: https://wiki.postgresql.org/wiki/Don't_Do_This

вообще очень ограниченный механизм

хорошо, продолжаем про секционирование. Вопрос: сколько строк с колонками типа bytea можно хранить в таблице? Ответ: значительно меньше чем хотелось бы, bytea хранится в TOAST, у которого идентификатором служит oid, он же unsigned int, т.е. даже в теории ограничение сверху - 4 миллиарда, что, нужно сказать, даже 10 лет назад было не чтобы очень много, но (!) мы же в базу не только вставляем строки, но еще и обновляем и удаляем их, и, о боже, иногда откатываем транзакции, поэтому счетчик TOAST расходуется значительно быстрее чем того хотелось бы. Здесь непонятно, что мешает разработчикам переделать этот oid с unsigned int на unsigned long, однако конкретно в этой ситуации в определенных случаях использование секционирования несомненно бы помогло (исключительно как maintenance история, как принято в других СУБД), но, увы, не работает как того хотелось бы. Таким образом, можно смело утверждать, что хранение в этой СУБД данных типа blob (да и вообще длинных строк, а сейчас пошла мода JSON хранить), довольно сильно ограничено, другими словами не работает (и не нужно здесь про «вы неправильно используете нашу распрекрасную СУБД»).

Кстати, про JSON: а оно умеет делать patch, как того ожидает пользователь этой распрекрасной СУБД или-таки полностью его перезаписывает не смотря на конкурирующие изменения? А то, помнится все несказанно радовались, что постгрес работает быстрее монги с JSON, а вот про обыденные вещи как-то забыли.

А как в постгресе обстоят дела и Direct IO и Async IO? Все также из кешей ФС данные дергает, да? Вот в MySQL, внезапно, оно-таки есть: https://dev.mysql.com/doc/refman/8.0/en/innodb-linux-native-aio.html

В MySQL тоже есть куча недостатков и специальных случаев. Я их специально не собирал и прямо сейчас не смогу составить сводную таблицу, но там тоже 100500 случаев произвольных ограничений.

Например, JSON на том же уровне, который в PostgreSQL (который, по вашим словам, хуже, чем в Mongo) в MySQL даже на таком уровне нет.

И если составить такую таблицу: ограничения MySQL, ограничения PostgreSQL, то я уверен, что столбец MySQL будет длиннее и проблемы в нём в целом будут серьёзнее.

Возможно, кто-нибудь даже уже составлял такие сравнения.

тоже есть куча недостатков

таки в итоге непонятно: «тоже есть куча недостатков» или «в нём всё продумано и сделано для людей»? «сделано для людей» - это где угодно, но только не в PostgreSQL.

таки в итоге непонятно: «тоже есть куча недостатков» или «в нём всё продумано и сделано для людей»? «сделано для людей» - это где угодно, но только не в PostgreSQL.

Совершенно точно также и MySQL не сделан для людей. Навскидку: экстремально кривое автодополнение в mysql cli (да и вообще редактирование). Многие SQL конструкции не поддерживаются (навскидку не перечислю), заметно более ограниченный набор поддерживаемых типов и операций над ними, а также типов индексов.

В не-последних версиях MySQL/MariaDB встречались совершенно детские ошибки парсинга SQL (сталкивался несколько лет назад, подробности не вспомню), а также совершенно дикие абсурдные костыли типа их самовыдуманной кодировки UTF-8-3, которая была серьёзной подляной для разработчиков, а главное - совершенно непонятен был смысл добавления подобного костыля - как будто разарабы постоянно под мухой, т.к. никакого смысла в подобном уродстве не было вообще.

Когда с этим столкнулся, специально пытался докопаться, кто же и зачем придумал эти грабли. И не только я пытался, но все попытки ни к чему не привели.

СУБД находится на уровне развития ниже MSSQL2005, а вы пытаетесь сравнивать различные СУБД на основе «удобства работы» в CLI, который оказывается востребованным дай бог раз в полгода, в оракловом SQL*Plus вообще нет ни истории команд, ни автодополнений, редактирование последней (только последней) команды реализовано через ed, однако по возможностям автоматизации сценариев даже эта «поделка» на голову выше psql.

Мы вообще-то сейчас MySQL с PostgreSQL сравниваем, а не с MSSQL или Oracle.

Ну и важное отличие PSQL от двух вышеперечисленных: она абсолютно бесплатна, тогда как не знаю насчёт MSSQL, но Oracle, когда продавался, стоил астрономических денег.

Ну и важное отличие PSQL от двух вышеперечисленных: она абсолютно бесплатна, тогда как не знаю насчёт MSSQL, но Oracle, когда продавался, стоил астрономических денег.

Ещё более важное — то, что открытая. Если наткнулся на неудобство, его всё-таки можно подправить, а не вагон костылей вокруг городить.

она абсолютно бесплатна, тогда как не знаю насчёт MSSQL, но Oracle, когда продавался, стоил астрономических денег

Вот ребята из темы (т.е. «Postgres Professional»), продают СУБД и поддержку к ней за вполне себе фиатные деньги, причем стоимость вполне себе сравнима с MSSQL.

Если наткнулся на неудобство, его всё-таки можно подправить, а не вагон костылей вокруг городить.

эти байки лучше оставить каким-нибудь студентам….

У постгресового MVCC есть одна «интересная» особенность: при достижении определенного количества «транзакций» в секунду, вероятность поставить базу колом невероятно возрастает, это даже в документации описано: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND (они правда забыли упомянуть, что подсчет на самом деле ведется не только в транзакциях, но сабтранзакции (savepoint и все nested begin) тоже учитываются - проблема довольно банальная - те же 32-х битные счетчики, и замечена она была довольно давно (вот относительно «свежее»: https://blog.sentry.io/2015/07/23/transaction-id-wraparound-in-postgres/ https://mailchimp.com/what-we-learned-from-the-recent-mandrill-outage/). За последние лет 5 им наверное уже патчей так 10 скинули, которые должны решить проблему, однако, воз и ныне там - вот такая вот открытость.

За последние лет 5 им наверное уже патчей так 10 скинули, которые должны решить проблему, однако, воз и ныне там - вот такая вот открытость.

Ну вот. Значит патчи есть и их можно поставить. А в MSSQL если вычисление теряет точность, просто смирись, поменять нельзя.

Помню когда то давно, когда везде рулил мускуль, а я только знакомился с СУБД, мне тоже сразубросилось в глаза что у постгреса и написано красивее и документация лучше, но основным аргументом тогда было то что постгрес нигде в интерпрайзе не используется, и никто не знает как он себя поведет под нагрузкой, а мускуль мол надежный и проверенный.
В общем же эти бд были абсолютно идентичны как по жирности так и по функционалу.

Postgres всегда опережал и опережает MySQL по поддержке стандартов и количеству фич. И 20 лет назад тоже опережал (но, возможно, не опережал по скорости).

А когда-то давно ещё в MySQL было множество подводных камней и нелепых неинтуитивных ограничений. Я лично минимум пару раз сталкивался с настоящими багами в MySQL.

Да, энтерпрайзы побаивались брать Postgres, но это история 20-летней давности. Да даже и тогда кое-где в энтерпрайзе использовался Postgres. Последние лет 10-15 в энтерпрайзе Postgres используется во все поля, и я даже отвык видеть где-либо MySQL, чаще всего он встречается в седом легаси, или у похапешников, выросших на WP.

что вы называете слоями совместимости - поддержка ansi sql ? есть что то кроме ?

да уже под нагрузкой его поюзали, нормально себя ведет и не падает, работу свою выполняет, правда медленнее ms sql на 30% местами

что вы называете слоями совместимости - поддержка ansi sql ?

Очевидно не только ANSI.

есть что то кроме ?

Есть ли в MSSQL и Oracle что-то кроме ANSI SQL? LOL

Почти у каждого из больших игроков есть свой коммерческий форк PostgreSQL. Вон Google в начале года запустили https://cloud.google.com/alloydb , который уделывает по производительности оригинал в 100 раз и решает ещё массу проблем.

Опенсорсная версия продолжает развиваться, но очень аккуратно, чтобы случайно не пофиксить какое-нибудь архитектурное ограничение на ровном месте, и тем самым не подломать кому-нибудь бизнес.

ну не знаю… лично для меня аргумент вида «наш продукт страдает от детских болячек, но зато другие люди из него сделали что-то работоспособное» несет скорее негативный оттенок, нежели положительный, т.е. здесь получается, что у разработчиков каких-либо серьезных планов в отношении продукта-то и нет, собственно о чем отсутствие багтрекера, роадмапа и прочих достижений современной разработки не просто намекает, а, скорее даже кричит.

не подломать кому-нибудь бизнес

вот что правда, то правда, если в ванильный PostgreSQL добавлять фичи и чинить болячки, то это без сомнения подломит бизнес всяким EnterpriseDB, 2ndQuandant и прочим около-постгресовым компаниям, нужно просто поддерживать продукт на плаву, чтобы он умел запускаться на современных операционных системах, изредка чинить баги и также изредка добавлять хоть какие-то фичи, в противном случае интерес к продукту просто-напросто пропадет и доить уже будет нечего.