Патч 1с сервер скачать

Патч 1с сервер.

Причем это максимальный уровень НЕ стандартен для типового PostgreSQL. Для дополнительной информации знатокам MSSQL следует обратиться к http://www.postgresql.org/docs/9.3/static/explicit-locking.html. Ключевые слова здесь: по умолчанию, максимальный, НЕ типовой. А это значит — если 1С-ный программист НЕ управляет блокировками, то PostgreSQL с точки зрения будет вести себя НЕ как PostgreSQL. Надеюсь идея понятна. Тогда, когда проводилось это исследование в стандарт 1С:Совместимо только-только включали требования явно управлять блокировками и тестировать производительность на стороне кода 1С на параллельность. А я уже своим программистам и себе рекомендовал тоже самое (в том числе типовые конфигурации, в которых не было управления блокировками для меня были уже не актуальными и в работу не брались — в таком случае писались свои системы, а с типовыми только интегрировались). И это всё?

Ну и последнее для данной публикации это патч вводящий новый тип, точнее «контрибьютящий» некоторой количество кода внутрь нашего «адаптированного для 1С PostgreSQL». И тут нам вдруг открывается, что оказывается можно собирать свой PostgreSQL со своим набором библиотек. Интересное знание, и прежде чем вы скажете, что мы должны использовать только нативное и без расширений, я вам скажу что функционал таких модулей http://www.postgresql.org/docs/9.3/static/contrib.html — это официальный нативный функционал. Казалось бы, что такое знание совершенно не полезно. Напомню, что дополнительных библиотек, которые собираются вместе со стандартными всего 5 в последнем (на текущий момент) патче. mchar fulleq fastrun ( опечатка сделана специально ;-) ) online_analyzer plantuner И вы знаете мне эти библиотеки понравились.

Причем каждая по своему: online_analyzer и plantuner – сразу нас приводят на сайт http://sigaev.ru/ для НЕ желающих ходить по ссылкам, сразу скажу – эти 2 модуля добавляют известное поведение MSSQL – USEPLAN и аналог AUTOUPDATESTATS. И мне понравилось – во-первых данные библиотеки сразу же были включены в Ruby on Rails проект (точнее в их PostgreSQL), где в тот момент в силу большого количества пользователей наблюдались проблемы с производительностью с PostgreSQL. Особенную проблему вызывала как все 1С-ники знают, проблемы со статистикой записей. А тут оказалось, что можно построить адаптивный план обслуживания. Просто в PostgreSQL функция UPDATE STATS из MSQL называется ANALYZE TABLE.

Необходимость использования «хинтов» для плана запроса, говорит нам о том, что в 1С знают, что их запросы, формируемые в виде SQL достаточно нетривиальны, а также о том что оптимизатор планов запросов PostgreSQL проигрывает тому же MSSQL, где прецедентов необходимости подобного было очень мало и чаще всего причиной являлся плохой код. Вместе с этим именно это знание послужило основанием для решения НЕ использовать 1C+PostgreSQL для 1С:Зарплата и управление персоналом, в связи с особенностями текстов запросов. Но тесты на 1С ЗУП 3.0 уже показывают обратное поведение в связи с переработкой модели и методологии, которые на несколько порядков упрощают запросы. Вообще поведение последних редакций больших типовых (УТ 11.1, БП 3.0, ЗУП 3.0) позволяет с уверенностью сказать о их адаптированном поведении к PostgreSQL и Oracle. Спросите – откуда здесь появился Oracle? Мало кто знает, но PostgreSQL очень похож на Oracle. Не функционалом конечно, в Oralce он на порядок мощнее, а заложенной методологией. Существует версия что PostgreSQL рождался как OpenSource ответ большому и дорогому Oracle.

Ключевым, наверное, термином здесь является PLpgSQL и остальные. Изучив PostgreSQL и его поведение, в случае если ваша компания захочет адаптировать 1С к Oracle, ваш опыт будет повторно использован, в силу особенностей архитектуры обоих. Ну и необходимо понимать, что PostgreSQL имеет версию и платную функциональность http://www.enterprisedb.com/products-services-training/subscriptions и цены там вполне себе Enterprise. Особенно для функциональности наподобие AlwayOn от MSSQL. На самом деле, если продолжать можно понять, что 3 остальных библиотеки mchar, fulleq и fastrun – то же добавляют интересную функциональность, и даже НЕ для решений на 1С платформе. Особенно интересен новый тип MCHAR, а также то зачем для него понадобилась библиотека ICU. Что дает нам понимания, что работа в том числе с UTF-8 при использовании чистого PostgreSQL будет и есть достаточно Не тривиальной задачей, с чем вы обязательно столкнетесь, когда начнете писать приложение, которому будет необходимо хранить строки в национальных кодировках – когда например ваше приложение будет иметь пользователей из России и Канады например, да еще с Китая в добавок. Прежде чем мы начнем спорить необходимо понимать какую функциональность содержит mchar.h и файлы mchar\mchar*.c.

Но для этого вам понадобится знания языка С для чтения кода. В сухом остатке. Теперь я могу точно ответить – «Мне очень нравится данный патч» . Надеюсь вы понимание почему?