Сравнение производительности MSSQL и PostgreSQL

Тема для тех, кто юзает обе СУБД.

В Инете нашёл несколько восторженных статей, что PG ни чуть не хуже, а в некоторых случаях даже лучше MSSQL по производительности.
Единственные нарекания только на оптимизатор PG, т.е., его производительность может упасть при очень сложных запросах

Во-первых, я что-то не так оптимистичен по поводу производительности в отношении PG. Во-вторых, он очень неудобный в плане отладки. Нет нормальных менеджеров. Причём функционал даже платных менеджеров не позволяет создавать индексы с включёнными столбцами, не участвующими в построении индекса (опция INCLUDE). Такая опция имеется только в pgAdmin, но он, сам по себе, уё...

У кого, какое мнение?

0

Сообщение от avm71 Причём функционал даже платных менеджеров не позволяет создавать индексы с включёнными столбцами, не участвующими в построении индекса (опция INCLUDE). Такая опция имеется только в pgAdmin, но он, сам по себе, уё...

Чё?.. Обычным запросом индексы в базе уже не модно стало создавать?..

0

Сообщение от Usaga Чё?.. Обычным запросом индексы в базе уже не модно стало создавать?..

Этож скока буковок нужно нажать и ещё слова нужно знать забугорные, а так крысой подавил по кнопкам и готово

0

Andrey-MSK, ну да) Кнопочку не дали - значит фича не доступна) Пойти почитать учебник? Да ну нафиг!)))

1

avm71, ты ответь, тебе купить или продать?
Если отбояриться от переноса унаследованного ПО с сикуела на постгресс - это один вопрос.
Если проект новый, и ты оцениваешь, чего брать [то ответ - однозначно постгресс (про), как не имеющий политических рисков, и вообще так положено по требованиям ЦБ РФ] - то требуется дополнительное исследование проекта.

2

Сообщение от avm71 в отношении PG. Во-вторых, он очень неудобный в плане отладки. Нет нормальных менеджеров.

Попробуйте dbeaver.

1

Сообщение от Ludwig Valentin Попробуйте dbeaver.

Это хорошая штука. Сами ею на работе пользуемся. Но у ТС проблемы на системном уровнем. Это лечится чтением учебника\документации по постгре в первую очередь...

Иначе он так и будет бегать в поисках "менеджера" с волшебной кнопочкой...

0

Переписываю готовый проект

Добавлено через 31 секунду
Тоже к такому выводу пришёл

Добавлено через 2 минуты
Все эти буковки я знаю - это простое удобство, если забыл, как построен индекс, заглянуть в его устройство.
а если так рассуждать, давайте на ассемблере всё программировать - там ещё больше букв

0

Сообщение от avm71 а если так рассуждать, давайте на ассемблере всё программировать - там ещё больше букв

Не надо до абсурда сводить мои слова. Я тебе предлагаю не буковки знать, а учебник по постгресу почитать. Или документацию. Чтобы знать как там можно легко и без менеджеров платных создать индексы покрывающие.

0

Сообщение от Usaga Чё?.. Обычным запросом индексы в базе уже не модно стало создавать?..

Переписать проект на другие лыжи в связи с рекомендацией для критически важных предприятий
Я знаю как строится индекс . Вы, как я погляжу любители ручной работы? Я привык при достижении результата пользоваться всеми доступными инструментами.
С помощью INCLUDE в индекс добавляются просто значения указанных колонок. Эти колонки в построении индекса (ключа) не участвуют. Индекс с неключевыми столбцами может значительно повысить производительность запроса, когда все столбцы запроса включены в индекс как ключевые или неключевые. Повышение производительности достигается, так как оптимизатор запросов может найти все значения столбцов в индексе и, в этом случае, нет необходимости прыгать за данными в саму таблицу.

Когда у тебя в проекте несколько десятков таблиц ты уже не помнишь структуру всех индексов. Очень удобно в интерфейсе менеджера ткнуть в индекс и увидеть его структуру.
Так вот, все менеджеры (платные и бесплатные), кроме pgAdmin видят столбцы из рубрики INCLUDE в составе ключевых столбцов.

0

Сообщение от avm71 Вы, как я погляжу любители ручной работы?

Ну это надёжнее и безопаснее, чем через UI. Ну т.е. посмотреть список/состав индексов ок, через UI это реально удобно. Но вот создавать/редактировать структуру БД через UI - слишком страшно, потому как каждый раз приходится гадать, что там этот платный/бесплатный инструмент нагенерирует.

Ну и на реальных проектах вообще не понятно, как через UI структуру БД менять - кто-то из коллег добавил/поменял индекс/таблицу/итп, описал всё это в виде SQL, закоммитил ... и при публикации проекта в прод/тест (или даже при запуске в локально в отладке) мне куда проще взять этот SQL из Гита, бегло оценить суть и потом просто выполнить, чем открывать UI, выискивать там нужную таблицу и там этот индекс мышкой повторять, читая SQL его создания/модификации.

P.S.: к тому же, разные UI-инструменты могут вести себя по-разному, иметь разные параметры по умолчанию, а ещё могут менять своё поведение при обновлении версии. А SQL-скрипт - он как работал, так и продолжает работать.

3

Сообщение от kotelok Ну это надёжнее и безопаснее, чем через UI

+ быстрее
+ UI могут помешать ограничения, которых не будет у скрипта
+ скрипты можно хранить в проекте/блокноте/ХП — быстро находить и быстро запускать, при необходимости

1

avm71, я не понимаю о какой ручной работе ты говоришь. И тем более о какой её улучшении в тыкании мышью в GUI менеджера.

У нас в проекте более шести сотен таблиц и вьюх. Мне не надо ничего такого обо всём этом помнить. Или иметь какой-то особенный "волшебный" менеджер.

Если мне надо посмотреть где что есть, я в DBViewer это делаю. А если надо куда-то что-то добавить, то это уже определённый ритуал, с созданием миграции базы. А это в любом случае ручная работа. В любом. Ведь эта миграция должна быть автоматизирована и воспроизводима. Чтобы другие разработчики могли воспроизвести. И тестировщики. И у пользователей оно воспроизвелось.

А то, что ты тут спрашиваешь - какой-то детский садик.

0

Сообщение от kotelok Ну это надёжнее и безопаснее, чем через UI. Ну т.е. посмотреть список/состав индексов ок, через UI это реально удобно. Но вот создавать/редактировать структуру БД через UI - слишком страшно, потому как каждый раз приходится гадать, что там этот платный/бесплатный инструмент нагенерирует.

...в том-то и всё дело. У MS SQL Очень надёжный UI (многолетняя эксплуатация) - проблем никогда не было, всё чётко. Потому и задаю эти вопросы, чтобы понять чего мне ожидать на этом новом поприще (переписывать БД на MS SQL в PG), и узнать у опытных людей, как грамотно управляться с PG - хочется сначала определиться с инструментами.

0

Сообщение от avm71 У MS SQL Очень надёжный UI (многолетняя эксплуатация) - проблем никогда не было, всё чётко

Ты не поверишь, но у MS SQL никогда не было и нет никакого UI... SQL Management Studio не является частью СУБД SQL Server. И более того: оно не является единственной админкой для этой СУБД.

0

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

P.S.
Т.к., альтернатив перехода от вражеского ПО нет, будем работать с тем, что имеем, с PG, тем более, что о нём очень много лестных отзывов. Но очень не привычно.

0

avm71, заметь: PG тебе тоже не очень дружеский. Только платный PostgreSQL PRO, который стоит как крыло от самолёта.

0

Добавлено через 1 минуту

Сообщение от Usaga avm71, заметь: PG тебе тоже не очень дружеский. Только платный PostgreSQL PRO, который стоит как крыло от самолёта.

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

0

Сообщение от Usaga Только платный PostgreSQL PRO

А вам нужна репликация?
Или купите хостинг у провайдера, или вы серьёзная фирма со своим интранетом и DMZ?

0

Ludwig Valentin, я не понимаю вопроса. Мы здесь чьи горести обсуждаем?

0