Раньше, помнится, были какие-то ограничения в сложных запросах..?
И/или что-то с транзакционной моделью ещё было...?

Суть в чём, предлагают вместо MS SQL перейти на PostgreSQL.
Будет ли хуже или уже всё 1:1?

А смысл?

Кто предлагает? Ты продаешь или покупаешь?

Будет не лучше, так наверное правильно сказать ))

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

(4) А что, у вас финдир - мастер DBA?

А ты там кем?

"перейти" - нет, "не купить MSSQL" можно попробовать.

(0) Что значит перейти?
Если у тебя сейчас MSSQL и он куплен, то нафига козе баян? Зачем менять? MSSQL однозначно лучше и мощнее.

Вопрос в том что если тебя файловая, а денег совсем нет на лицензии SQL, то тогда однозначно переходить на Postgree.
Проблемы будут, но не смертельные. Все равно это лучше чем файловая

(5) Финик пади увидел стоимость скуля и в курсе за бесплатные аналоги

(5) Просто нужно обоснование без воды...

С блокировками может быть беда. Давно пашем и без проблем в целом. DBA есть.

(11) Разделение итогов уже умеет?

(0) Что мешает установить и проверить?
Мое мнение: лучше MS SQL.

(9) так "продать"-то не получится.

(11) Технические подробности можно?

(0) Большие базы-то? Или бухгалтерия на 5 пользователей?

(14) Почему?

(16) Планируются большие, но пользователей не больше 50 наверное... Самописки

(12) Разделение итогов это функционал 1С.  Postgres паралелил запросы плохо. Давно все поправлено.

(15) Технические подробности чего?

(14) Вопрос не финансовый купить/продать и т.д.
А чисто технический, остальное всё решено

(18) Самописки вам боком выйдут скорее всего, будете переписывать. Типовые все уже заточены под слона.

(19) Проблем с блокировками

Меня можете пинать - но если вопрос о деньгах не стоит - я бы взял МС.

(19) Понятно что это функциональность платформы. Херово оно в Постри как-то работало (подробностей не помню).

(21) Что именно переписывать то? Мы не используем прямые запросы к MS SQL

(25) *овнокод на встроенном языке 1С конечно же

(23) Вопрос не в деньгах. Но без чёткого обоснования то же не прокатит. "Я думаю" не котируется

(26) я написал с сарказмом... хоть один кусок бы кода увидеть, SQL-зависимый

(28) Любой запрос с полным соединением

(27) Хорошо. Мой опыт (без малого 20 лет) просто таки орёт за МС.
Так покатит? )))

(29) первая техническая подробность в данной теме! ура!

Linux админы есть у вас?

(30) Нет, так как на другой стороне найдётся противоположность с опытом работы на постгри 21 год

под винду брать постгре нельзя

(32) есть, штат

(35) ну тогда берите постгре. почему бы и нет

(33) 21 год на постргре - это нереально.

(22) Это проблема не SQL сервера. Стандартные конфы изкоробки умеют гибкие блокировки.

(29) Запрос с полным соединением - уже моветон.

(30) Мой опыт говорит - "никогда не слушай людей, которые говорят - да мой опыт ххх лет".

(36) вот я и спрашиваю, почему нет то? В (29) начали отвечать

(37) Почему?  Слону 23 года как раз.  А до этого был Ingres.

Коллеги, хотелось бы по делу...

По хорошему нужно нагрузочное тестирование провести, насколько конфа готова к постгре

Так и обосновывайте: для выбора МС или Постгре нужно провести нагрузочное на постгре.
Цена: ХХХ руб
Цена Мс: YYY руб

(42) нагрузка - это одна сторона медали...
Вторая сторона - баги, фичи или не решаемые прямым путём проблемы

(42) и тестирование админов, спросить как они будут ловить проблемные запросы, сеансы, бэкап восстановление, ио на диск

(44) ну собственно все и увидите

(41) А что ты хочешь по делу то?  Да 1С работает на Postgres, хорошо работает.  

Начиная с 8.3.13 и 10 версии работает со стандартной Postgres.  

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

(44) Не решаемых не бывает.

Технически описано тут:
https://its.1c.ru/db/metod8dev/browse/13/-1/1981/1987

Опыт:
https://youtu.be/3k3IVwQLnQM?t=1846

(46) Конфигурация только разрабатывается, сдаваться будет в течении года блоками.... не применимо

(49) тогда вообще проблем нет, будете писать сразу как нужно

(47) Именно этого и хочу услышать - что нет не решаемых проблем и что всё 1:1

(50) как нужно то? где список того, как не нужно????

(51) у самой 1с фреш на постгре

(31) СрезПоследних еще

(53) ну им то все фичи известны... у них наверное есть список того, как не нужно делать )))))

(54) с ним что не так? где почитать?

(20) https://coub.com/view/4yvcg

(54) Это инфа от 8.2.  Давно починили.

(58) В 2018 году на партнерке представитель 1С по-прежнему говорит, что "соединение со срезом последних в Постгри может работать медленно". Возможно это уже что-то другое.

(35) + (49) = Постгри.
Все равно вряд ли на ваших самописках будет заметна какая-нибудь деградация.

(0) с полным соединением бывает засада, неоптимальные запросы сиквел тащит лучше но тоже с трудом... никто не любит в 1 запросе много соединений, но постгри совсем этого не любит.... и самое главное: постгри под окнами - недопостгри

(8) // MSSQL однозначно лучше и мощнее.

ну такая однозначность не для всех очевидна

(56) // с ним что не так? где почитать?

Это боян, который один и тот же акк на мисте пихает всем все годы существования постгри.

Боян этот много лет тому назад поправлен, но если тебе интересны детали, то гугли и будет тебе щастье.

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

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

з.ы. Кстати, никто из ярых адептов мс скл не давал себе труда подумать, а за каким вообще фигом майкрософт вкладывается в разработку версии своего мс скл для линукс платформы?

Если ничего нет, можно ставить Постгри, НО! только на линукс. Под винду на инфорстарте недавно описывали баг со статистикой, связанный с особенностями NTFS. Рано или поздно его поправят, но на неродной платформе все равно что-то обязательно будет вылазить.
На линуксе бояться нечего, опыт нескольких предприятий.
Если же речь о переходе с MS SQL, то соглашусь - нафига? Есть же уже рабочая система, "что работает - не трогай" :)

(64) один фиг фарш обратно не провернешь

(64) Это было давно и не правда. Vacuum и статистику с тех пор починили уже давно. Хотя смысл платить за лицензию на WinServer, если можно не платить?

(66) этот баг только в последнем релизе 10.6 починили.

(63) Другие платформы просто используются, 1С впервые...

(0) В 2013 году перешли с MS SQL на PostgreSQL.
В целом было все хорошо.
Но у PostgreSQL по умолчанию идет блокировка таблицы, а не записи как MS SQL.
У нас РИБ, как итог, когда шел обмен все сидели курили. В итоге через 3 месяца вернулись на MS SQL.

(69) > Но у PostgreSQL по умолчанию идет блокировка таблицы, а не записи как MS SQL.

Баг в 1С полагаю, а не в PostgreSQL?

(70) ну да. И все последующие платформы после 2013 года этот баз пофиксили. Причем, не только тех установках, что линукс-серверах, но и в тех, что на винда-серверах

(69) (70) "я худею дорогая редакция"

только на автоматических блокировках, которых лет 5+ нет на типовых....

(71) какой, блин, баг? Вы все не проснулись до сих пор чтоли?

(15) > Технические подробности можно?

Зачем? Для чего финдиру технические подробности?
Для финдира значение имеют только два параметра:
1. Деньги. (если MSSQL уже куплен, то вернуть их не получится).
2. Риски.

Если у вас типовые конфигурации на УФ актуальных релизов, то риски минимальны. 1С-овцы пишут код с учётом всех особенностей Postgres.
Если у вас самописки, то могут быть трудности, связанные с кривой работой Postgres с временными таблицами (например, безумные тормоза на запросах к виртуальным таблицам срезов регистров сведений). Хотя проблема эта была актуальна для старых версий и, вроде как, в последних её купировали.
Еще могут быть проблемы если базы работают не в режиме управляемых блокировок.

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

В остальном Postgres и MSSQL примерно одинаковы. На средней загруженности системах разницы вы не заметите.

(68) ну тогда такую историю расскажу

1. 1С можно и очень желательно ставить в трех-звенной свзяке.
2. сервер приложений (или приложение кластер серверов)может быть как на винде, так и на линукс
3. Когда сервер приложений вставлен на винде, то он умеет подключать сервера СУБД всех ему известных видов.

Так вот из пункта 3 следует, что большая часть проблем СУБД оказывается скрыта за слоем сервера приложений. И большая часть проблем 1С не имеет прямой зависимости от того, с какой СУБД она работает, а это проблемы платформы "1С-сервер" - старые исправляют, но и новые добавляют.

з.ы. А баг с конфликтом постгри с дисками нтфс возник не потому что постгри, а потому что обновление в майкрософт выпускали, которое безопасность должно было повысить. Вот и повысили, что пришлось вслед за этим обновлением и постгри обновление выпускать.

Если есть деньги, то однозначно MSSQL

(73) ну как какой?! обычный легендарный баз из 2013-го года, на неведомом релизе субд и неведомом релизе платформы.

(74) >По MSSQL спецов как грязи
реальных спецов мало, но каждый второй - самоназваный специалист высочайшего уровня

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

(79) "реальные скл-спецы не испытывают религиозной вражды к разным скл-субд"
Ну да... Сколько на форумах флейма про версионники вс блокировочники...

На одном видел даже реальное предложение мордобоя )))

на постргри раньше еще на восстановление из бэкапа жаловались
типа бэкап есть, но восстановиться из него либо совсем нельзя, либо только после танцев с бубнами и приношением в жертву девственницы под кровавой луной
------
щас норм все с восстановлением из бэкапов постгри?

Главная беда Postgres из того, что я читал - RLS в типовых. С их включением они помирают. 1С собираются этот механизм переделывать, видимо, как раз с прицелом на Postgres.

(82) это да! Могу подтвердить, что именно так и происходит - умирают в RLS. Может чего-то можно и донастроить, чтоб не умирала, но все что мне приходилось пробовать с включенным RLS было очень болезненно. Но справедливости ради надо сказать, что и при ms sql тоже очень сильно ухудшается работа, если сравнить работу без RLS и после его включения.

(83) То-то они разделители для фрешей своих с нуля придумали

(81) Все норм, проверяли на днях

(84) Внутри все равно РЛС работает.

(78) > реальных спецов мало

Согласен. Но большинство несложных проблем гораздо проще решить на MS SQL.
Даже если тупо взять задачу по настройке и особенностям всех регламентов СУБД для 1С. Для MS SQL миллион статей с картинками и пошаговыми подробнейшими описаниями. Так что даже школьник разберется. Для Postgres с этим гораздо сложнее.

(87) у ТС же целый штат админов

(88) Вопрос только - каких админов. Если DBA, то вопросов нет - трудностей возникнуть не должно. Если просто системных администраторов, которые СУБД знают на уровне - как поставить и пнуть, чтобы заработало, то тут могут быть проблемы.

(89) заметь, проблемы могут быть на любой СУБД

(87) по PG может не миллион статей, но тоже более, чем достаточно.

(82) в БСП 3 переделали

У пострегреса внятная официальная документация. С недавних пор и на русском языке. Но школьники, они такие, продолжают учится по комиксам.

(90) Совершенно верно. Поэтому если у автора есть нормальный(ые) DBA, то они разберутся в любой СУБД - хоть MS, хоть Postgres. Если нет, то вероятность быстрее разобраться с MSSQL выше так как заметно больше в сети есть материалов по этой СУБД.

(93) +1

(92) В типовых это не внедрено? Кто-нибудь проверял эти новые РЛС на постгри?

(96) ну запрос там явно проще. см шаблон #ДляОбъекта(…) (в документации к БСП описания почему-то нету)

ну и http://downloads.v8.1c.ru/content//SSL/3_0_1_287/change.htm в разделе "управление доступом"

(92) оптимизировали просто? принципиально же врят ли что-то поменялось

(98) "убрана форма одной синхронизации. Все настроенные в программе обмены отображаются в виде списка" // Ололо, не прошло и 10 лет )

(99) прям принципиально

ну и разрабатывать легче стало

(102) так вроде и раньше было всеголишь процедуру 1 вызвать

(103) сейчас у тебя правила RLS в коде, а не в роли, как раньше. соответственно, доработка намного проще.

(104) получается справочник ролей РЛС сделали?

(105) скачай демо базу, да глянь. в документации пусто почти :(

Работает достаточно адекватно. Плюсов много. Под Windows тоже неплохо оптимизировали.

(0) на инфостарте будет доклад про это

(105) Велкам ту БСП3. Написано на EDT - писали java-бои. Обращений к SQL по мелочи стало в разы меньше, но найти "сцукобаг" стало сложнее без знаний платформы, или установки этого EDT?

(107) Там все нормально было под Win.  Просто все же слишком крутые спецы, чтобы читать документацию.

(110) В 8.4 под Windows проблемы были. Это точно. В современных версиях пишут, что почти сравнялись по производительности с MSSQL. На Linux сервере мне сейчас даже больше нравится, чем под MSSQL, но только того, что касается оптимизированных конфигураций под 8.3 (т.е. современных). А вот с самой удачной УТ 10.3 и в защищенных приходится работать под MSSQL, т.к. любители винды не хотят, чтобы все это запускалось и работало под Linux серверами, да и изменений много.
Вот выйдет 10.3.14 и думаю переехать на PostgreSQL 10. Давно уже пора.

(111) На ут 11 давно переезжать пора.

(112) Смысл?

(111) тут больше не о версии SQL нужно думать, а ломать голову в какой из версий платформы лучше быть - наплодили!

(112) Не для оптовых баз эта конфигурация. Многое из 11 выкинули, что было жизненно необходимо. Я уже не говорю о всех изменениях, что было внесено за 10 лет работы. Да и тормозная она слишком.

(99) Подробная презентация изменений РЛС
http://fserver.1c.ru/its/files/public/erp/train2018/d1_17_30.ppt?_=1535467501

(116) это в презентации уже типовое решение описано и доработка на каком-то индивидуальном проекте?

(117) Думаю, описано то что вошло в БСП, т.к. в версии 3 объекты метаданных по крайней мере есть такие же (справочник КлючиДоступа, например)

У меня PostgreSQL 10 вообще не запустилась!
Переходим сейчас с 9.4 на 9.6.

(118) ок. спасибо, надо будет тоже посмотреть как там теперь в КА2 работает

(119) у нас 10ка стала загружать при расчете себестоимости или перепроведении все ядра на 100%, до этого по 1-2 ядра было загружено. Десятка рулит.

(119) что сказала?

(121) официальная сборка от 1С или стоковый+патч?

(123) одинэсовская

(107) в целом да, постгрес даже на windows неплохо работает, но я недавно столкнулся с новым приколом :
КА 1.1.107.4 - проблемы с архивацией на СУБД Postgres Pro
Пока не разобрался в чем проблема и как решать.

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

(125) можешь ради эксперимента поставить мс скл (лицензии ведь не аппаратные и не программные, а чисто бумажные) - проблемы в КА 1.1 все равно будут возникать

(127) Это серьезно? Ты нигде не опечатался?

(128) в чем, в том, что нет программно-аппаратных ограничений на установку МС СКЛ ?

(129) в том что ms sql не переварит нормально КА 1.1

(130) ты не понял смысла моего поста - проблемы при работе с КА 1.1 возникают на уровне используемой платформы, а не СУБД : ты решишь трабл с архивацией, но наступишь на грабли с применением обновления и т.п.

(126) "Сами базы на конфигурации КА 1.1 уже дошли до такого состояния, что с них обязательно нужно уходить"

Что за состояние такое?

(132) продолжать обсуждение КА 1.1 в данной ветке - совсем уже оффтоп будет

(132) для примера вот смотри по ссылке из (125) - там посты 16 и 17.

Не хочу пытаться дальше спорить, но у меня неоднократно возникали подозрения, что скажем так системная часть конфиги КА 1.1 от поставщика просто уже содержит повреждения. Как их исправить не известно, а нормальной эксплуатации это все сильно мешает. И повторюсь - использование мс скл не излечивает от этих проблем полностью, а траблы все рано живут себе дальше.

А нет, вспомнил! Есть одно лекарство - снять конфигу с поддержки полностью и бесповоротно.

писала уже про постгре кому-то, повторюсь :

На практике столкнулась с вот этим  :
https://its.1c.ru/db/metod8dev#content:4208:hdoc
Пришлось переписать ряд тяжелых запросов.

Кроме того, буквально недавно  пришлось быстренько уходить с постгре на скуль. Все потому что неоперативное проведение документов вызывала дикие тормоза в одной базе ( бух2.0) , а в другой на этом же сервере ( ут10_3) все жаловались , что не могут работать. Перенесла базы на скуль  - и все отлично. даже где-то видео осталось разницы.

И потом, поддержка постгре сложнее, не все это умеют и могут )

(135) > На практике столкнулась с вот этим "Оптимизация использования виртуальной таблицы СрезПоследних при работе с PostgreSQL"

Вроде как, в последних версиях Postgres эту проблему пофиксили. Связана была с особенностью работы Postgres с временными таблицами.
То есть сейчас эта статья по сути не актуальна.

(135) это ссыль от декабря 10-го года!!!

Баг оперативно пофиксили прямо в платформах 1С (году в 2011-ом или в 2012-ом) и теперь на живых базах не встретишь ни тех релизов скулей, ни релизов платформы, более того, даже конфигурации все типовые пофиксили, чтоб не вылазили подобные баги наружу

(135) На БП 2.0 скорость закрытия квартала с полным перепроведением всего после настройки postgresql.conf не хуже ms sql

(137) дело было в 2015 году.
Допускаю, что был не самый свежий постгре. Обновлять постгре ну вообще не было никакого желания. Да и знаний, че уж.

Сегодня ванильную PostgreSQL 11 выпустили.

(69) А на РИБ когда идет обмен при любом случае все сидят курят, нет разве?

(141) Смотря как настроена запись при загрузке (какими порциями в транзакции) и какова интенсивность записи в результате работы пользователей. Всегда можно успеть вклиниться между транзакциями загрузки.