Статья. V7.7: Ускорение 1с под SQL (практическое руководство) #157337


#0 by Ильмар
Пользуйтесь на здоровье. В первой части изложена оптимизация бухгалтерской системы.
#1 by Diter
5. Постарайтесь минимизировать количество субконто. В большинстве случаев хватает двух. остальную аналитику можно получить путем: - использование дополнительных субсчтетов. - забалансовые счета - регистры оперативного учета - дополнительные справочники не согласен в корне. я своих бухов пинаю за такие вещи. нельзя аналитику формировать за счёт субсчетов
#2 by Ильмар
Аналитику можно вести не только на субконто. См. остальные два варианта.
#3 by Скользящий
А чем ToySQL не нравится?
#4 by КонецЦикла
Опер. учет форева!
#5 by Ильмар
3. Причем здесь ToySQL? Не нужно все сваливать в одну кучу. Речь об оптимизации, а не об альтернативных запросах. 4. Да, он пошустрее. Но бухгалтерская система также нужна, реализовать ее на оперативном учете нерационально.
#6 by КонецЦикла
Были и такие преценденты (читал внедрения) :)
#7 by Скользящий
Причем оптимизация на ToySQL проще и надежнее, чем твои драные куски кода.
#8 by Ильмар
6. для меня это не новость.
#9 by Ильмар
7. Боюсь, ты просто не понял о чем речь, ввиду недостатка квалификации. Рекомендую более тщательно изучить предметную область.
#10 by Скользящий
Хм. Почитай на территории 1С каменты к твоей оптимизации. У них надеюсь квалификация нормальная?
#11 by Ильмар
Статья для продвинутых пользователей, а не для начинающих. Кто не хочет, пусть не читает, не заставляю.
#12 by Дом Мебели
Ильмар, продолжение будет? Нам помогло, но хочется большего.
#13 by PR
А не Матрейя ли здесь сам с собой разговаривает? :o)
#14 by Diter
Конечно он.... у меня такое ощущение, что у него запой дня на три-четыре....
#15 by pvase
Вообще идея хорошая, подерживаю, но мало текста и непонятно зачем. Может сначала теорию в студию запустить, а потом практическими примерами додавить.
#16 by romix
Меня порадовал метод получения строки подключения из DBA в .. Там что ли почти простое гаммирование по XOR? :-)
#17 by AAAChel
А мне больше всего из второй ссылки понравилось: "Некоторую часть оперативной памяти следует оставить для Windows NT..." Видимо обычно ей не оставляют бедной памяти, а работает))
#18 by Ильмар
15. Теории, ИМХО, и так хватает в инете. Была цель - именно практическое руководство, то есть почитал-реализовал. 16. Автор кода некто Docent. В своем руководстве я часто использую алгоритмы, которые видел в разбросанном виде в инете.
#19 by Дом Мебели
Ильмар, Вы так и не ответили на наш вопрос. Продолжение статьи когда будет?
#20 by toypaul
отключение галочек отборов может привести к проблемам при проведении документов и формировании бух отчетов. смысл остального кода не понял. если начинающие будут применять это к своим базам...хм...их могут повесить за "одно место".
#21 by toypaul
вообще кошмарная и бестолковая "статья". после удаления проводок (пускай пустых) не производится пересчет итогов. хотя бы ссылку на источники теории давали, чтобы люди сами могли разобраться что к чему.
#22 by toypaul
аналитика на субсчетах - согласен. это поможет при настройке механизма собственных блокировок.
#23 by toypaul
вообще для параллельного проведения если реализовать счета на регистрах было бы очень здорово!
#24 by Ильмар
20. "отключение галочек отборов может привести к проблемам при проведении документов и формировании бух отчетов" - поясни плиз. Рекомендую почитать методички 1с по оптимизации конфигураций под SQL. 21. Дело в том, что итоги хранятся в счетах, но никак не в проводках. Это не регистры. И в контексте приведенных алгоритмов итоги по счетам никоим образом не пострадают. 22-23. Речь пока идет об оптимизации, а не о паралельном проведении.
#25 by Ильмар
Выдержка из методички 1с. Бухгалтерские отборы При разработке конфигурации с использованием компоненты "Бухгалтерский учет" весьма важным моментом с точки зрения производительности является установка режимов отбора для бухгалтерский объектов. Существует несколько режимов отборов, которые можно установить в конфигурации для объектов метаданных, специфичных для компоненты "Бухгалтерский учет": · Отборы по данным операции (сумме операции, содержанию, реквизитам операции) · Отборы по данным проводки (сумме, количеству, валютной сумме, валюте, реквизитам проводки) · Отбор по счетам (в целом, с ограничением по уровням, по дебету/кредиту) · Отбор по видам субконто. Как и графы отбора документов, отборы бухгалтерский объектов могут использоваться как для ограничения визуального просмотра журнала операций и журнала проводок, так и для оптимизации получения различных итогов, а также выборки операций и проводок в различных алгоритмах. Для конфигураций, которые предполагается использовать на предприятиях с небольшим объемом проводок, можно задействовать те виды отборов, которые удобны пользователю для просмотра журналов. Однако для предприятий с большим объемом проводок рекомендуется внимательно рассмотреть целесообразность включения отборов, так как их использование может оказать существенное влияние на производительность системы. Прежде всего, рекомендуется проанализировать те отборы, которые используются исключительно для удобного просмотра журналов. Обычно это отборы по данным операций и проводок (суммам, содержанию, дополнительным реквизитам). Можно рекомендовать отключить такие отборы, так как они несколько замедляют запись операций, а при большом объеме информации реально могут и не применяться пользователями. Разумеется, отборы по данным проводок используют больше ресурсов системы, так как самих проводок обычно существенно больше чем операций. Так, например, отбор по сумме проводки, может использоваться только для удобства визуального просмотра, но при большом объеме проводок вероятность его реального использования невысока. Вместо отключенных отборов можно рекомендовать пользователям применять различные режимы поиска в журналах, а также различные отчеты. Отдельно следует рассмотреть отбор по реквизиту проводки, используемым в качестве разделителя учета, так как его наличие используется системой для получения различных итогов, ограниченных разделителем учета. Отбор по счетам играет особую роль среди бухгалтерских отборов. В отличие от отборов по данным операции и проводки, отбор по счетам требует больше ресурсов, так как одна проводка может относиться к нескольким счетам. Для поддержания отбора по счетам ведется специальная таблица вхождения проводок в отборы по конкретным счетам. В зависимости от установок отбора по счетам туда могут включаться, в том числе, и вхождения проводок в счета-группы в случае, если в проводке используется субсчет. В этом случае ресурсы системы расходуются тем больше, чем больше средний уровень вложенности счетов, используемых в проводках. Отдельный режим включает возможность использования отбора отдельно по дебету и кредиту проводки. Он также увеличивает время записи проводки. С другой стороны отбор по счетам не только обеспечивает удобный режим выборочного просмотра проводок, но и активно используется системой при получении различных данных объектом "БухгалтерскиеИтоги". Например, при получении карточки счета или анализа счета по датам. При проектировании конфигурации следует соотнести частоту формирования таких отчетов и затраты ресурсов системы (как по объему данных, так и по времени записи операции). Например, можно предложить следующее компромиссное решение. Отбор по счетам включается, но не включается отбор по дебету/кредиту. При этом отключается режим "для всех" и устанавливается параметр "количество уровня" равным 1. В этом случае доступным будет отбор проводок только по счету в целом, то есть не будет возможность просмотра проводок в дебет или кредит конкретного счета, а только всех проводок с данным счетом. Кроме того, отбор в журнале проводок можно будет установить только по счету верхнего уровня, и нельзя будет отобрать проводки по отдельному субсчету. Однако возможность отбора проводок по некоторому счету 1го уровня в большом количестве случаев будет вполне удобна. С другой стороны для большинства обращений к объекту "БухгалтерскиеИтоги" по конкретному счету данный отбор позволит существенно оптимизировать получение необходимых данных, даже в случае если происходит обращение к итогам по субсчету. Аналогично следует рассмотреть установку отборов по видам субконто. Как и отбор по счетам отбор по субконто используется не только для удобного просмотра проводок по конкретному объекту аналитики, но и используется объектом "БухгалтерскиеИтоги" при обращении к бухгалтерским итогам и операциям по конкретному субконто, например, для получения карточки субконто. Так как каждая проводка может включать разные объекты аналитики, то для поддержания такого отбора ведется специальный список, в котором отмечаются все вхождения проводки в отборы по тем видам субконто, в которых включен отбор в конфигурации. То есть количество записей в этом списке будет зависеть от частоты использования в проводках значений субконто тех видов,  для которых в конфигурации установлен режим отбора. При проектировании конфигурации следует соотнести необходимость быстрого получения отчетов по отдельным объектам аналитики конкретных видов с затратами ресурсов системы на поддержание отбора по субконто. При отсутствии необходимости быстрого формирования отчетов по отдельным объектам аналитики можно рекомендовать не включать отборы по субконто. Очевидно, что не имеет смысла включать отбор по тем видам субконто, количество значений которых невелико, например, по перечислениям. Значительный эффект при построении отчета может быть получен по тем видам субконто,  которые  имеют большой разброс значений в проводках, например, по организациям-контрагентам или товарам. Рекомендуется включить отбор только для тех видов субконто, для которых это действительно необходимо и дает ощутимый результат. Если отбор по субконто не дает существенного выигрыша при работе с бухгалтерскими итогами, то при большом объеме проводок можно рекомендовать не использовать данный отбор для визуального просмотра проводок и отключить его в конфигурации. Это уменьшит время записи проводок. Следует заметить, что при работе с базами данных в формате SQL существенно меняется производительность выборки данных объектом "БухгалтерскиеИтоги" и выборки проводок объектом "Операция". Поэтому для этих информационных баз, часто, отпадает необходимость в использовании бухгалтерских отборов для оптимизации построения отчетов и выполнения расчетов. Кроме того, и визуальный отбор в журналах при работе с базами данных в формате SQL может быть заменен построением соответствующих отчетов. Таким, образом, в большинстве случаев при переходе на версии для SQL имеет смысл рассмотреть возможность отключения бухгалтерских отборов, так как их поддержание также будет требовать определенных ресурсов при записи операций, а выигрыш от их использования, возможно, будет не существенным. Использование "длинных путей" при записи операции При формировании проводок в процессе проведения документа в алгоритмах определяющих различные данные проводки рекомендуется не обращаться к данным субконто или счетов через атрибуты объекта, "Операция", а обращаться через те переменные или реквизиты документа на основании которых эти данные заполняются. Обращение к характеристикам субконто и счетов через уже заполненные атрибуты проводки может существенно снизить производительность, так как при каждом обращении будет выполняться поиск значений типа "справочник", "документ" или "счет" в информационной базе.
#26 by Ильмар
19. Продолжение постепенное будет, в том же топике на Нью-Территории 1с.
#27 by softpoint8
Бредовая статья. Критиковать не буду потому как критиковать можно почти все. А вообщем то сразу чуствуется когда специалист сам проводит исследования и когда нахватет кусков из разных мест не понимая сути и в результате получается каша.(а вообще то мне это кого то напоминает:)) А вообщем то даже и спора чуствую не получится. Так мало людей действительно подходят к исследованиям серьезно. То All. Как минимум две рекомендации(измененные процедуры) приведут к тому что в вашей БД со временем данные будут рассогласованы.
#28 by Ильмар
27. заявлять пустословно - труда много не надо. Докажи свои утверждения, только не образно плиз.
#29 by МуМу2
Пожалуйста. Например изменение этой процедуры _1sp__1SENTRY_MaxRowID в текущем контексте без учета определенных ситуаций приведет что проводки будут привязаны не к той операции. Объясни какой смысл убирать блокировки с "проводок и операций" при этом оставлять на "журнал документов"? Вообщем то мне все лень честно говоря перечислять. Если бы в статье был бы описан смысл этих действий , логика(пускай и не правильная) то я бы может конструктивно бы рассказал. А так впечатление такое как будто студент списал курсовую кусками с учебника, кусками с других курсовых и не понимает общего смысла. Писать рецензию в подобном случае - терять свое время.
#30 by Ильмар
29. Изменение процедуры получения идентификатора позволит лишь записывать проводки, операции паралельно. Сбоя записи не призойдет, поскольку не отключены (в данном контексте) блокировки документов. То есть операция всегда будет иметь документ, проводки - операцию. Если ты можешь оспорить эту ситуацию - велкам, не можешь (не хочешь) - тогда не нужно пустых заявлений. Как известно транзакция проведения заключает в себя несколько действия. Если действие записи проводок-операция будет паралельным, то вся транзакция выполнится быстрее, хотя конечно и здесь есть ограничения...но в целом, приведенный код увеличит скорость проведения по бух.системе.  Если готов (в состоянии) поговорить предметно - можем поговорить. Что касается  сравнений со студентом, то я видел немало 40-50 летних программистов, знающих всего лишь пару низкоуровневых програмулек и методов и возомнивших себя спецами... Вот только любили они больше поговорить, чем решить реально проблему. Думаю, ты из таких. Старых бывших спецов, которые в текущем времени являются ламерами.
#31 by МуМу2
То 30. На каких релизах ты интересно это тестировал? Методы получения идентификатора последней (а хуже - иногда объекта)вставленной записи отличаются к слову говоря на различных релизах. Опять таки не вижу смысла зачем убирать блокировки с "проводок и операций" при этом оставлять на "журнал документов"? На этот вопрос сначала ответь. Если интересно то почитай мои статьи, например про технологию "гибких" блокировок, к слову написаную уже очень давно.(она уже устарела и описана в ней лишь небольшая часть айсберга) Это моя фотка - Как видишь я не стар - я суперстар:) Так что ты опять ошибаешся.
#32 by syktyk
Ай, молодца! Так все быстро пробил... Красивая у тебя аргументация. А я видел много недоучившихся студентов, которые выучив пару методов мнят себя крутыми спецами, а врезультате не понимая взаимосвязей рушат системы :(
#33 by МуМу2
Сразу хочу принести извинения перед студентами.:) Среди них есть очень толковые спецы. Но к сожалению их очень мало. Регулярно провожу собеседования - процент очень маленький. Основные минусы - недостаток практического опыта, завышенная самооценка(опять таки юношеский максимализм), недисциплинированность обусловленная тем что работать с 9-и до 18-и практики нет.  Cам был раньше студентом, сам был таким. А вообщем то я студентов очень уважаю:)
#34 by syktyk
Это выпад против меня? Зря...
#35 by syktyk
+ Снимается :) Вот я горячий северный парень :)
#36 by МуМу2
То 34. А ты студент?;) Извини не знал. А вообщем то что я написал это относится к большинству. Я же пишу что всегда есть исключения. Разумеется 33 это мое ИМХО.Правда с хорошей статистикой, да и на эту тему много было уже статей. Своего рода недостаток нашей образовательной системы а именно отсутсвие практики на реальных предприятиях по специальности. Впрочем это ОФФ. Предлагаю тему студенчества либо обсуждать отдельно либо закрыть.
#37 by syktyk
Улыбнул :) Нет, я думал, что ты на так сэрегировал :)
#38 by Ильлмар
31. 23 релиз. Но на 25 тоже будет без проблем (но это уже ИМХО). Что касается реализации гибких блокировок - они буду озвучены в шагах так 12-15... Не следует рассматривать описанный по ссылке шаг №1 никак, кроме как в контексте шага №1. Меня попросили написать руководство, растянутое во времени... По конкретной аргументации с удовольствием подискутирую на Нью-Территории 1с. Я не отрицаю ни чей опыт, с удовольствием его приму...но также постараюсь защитить и свою точку зрения.
#39 by softpoint8
То 38. Это все равно что учить управлять самолет с упражнения на посадку. :) Заметь, я на конкретные вопросы отвечаю, ты - нет. Вообщем как и предпологал опять игрушечки, несерьезно это. Но при этом игрушечки опасные , потому как если такие вещи делать без понимания то можно такого накуралесить... Я уже не раз разгребал после горе автоматизаторов.
#40 by Ильмар
39. Как раз наоборот, на конкретные вопросы отвечаю я, а ты занимаешься пустоблудием. При этом утверждаешь о каком -то разгребании после автоматизаторов... Полагаю, этот горое автоматизатор ты как раз и есть. Очень большие сомнения в твоей квалификации.
#41 by МуМу2
То 40. Опять Матрейя?!!! Устал , не могу больше спорить.:) Ответь на конкретный , важный вопрос- Какой смысл убирать блокировки с процедур на проводки и операции и не убирать с общего журнала документов?! (Я в твоих действиях смысла вообще не вижу. Просвети неумелых.)
#42 by МуМу2
+41. Да и кстати, ты в используешь термин "гибкие блокировки". Ты вообще в курсе откуда появилось это словочетание!? Поинтересуйся на досуге.:) К слову это словосочетание,(технология позднее) будет скоро защищено как бренд(документы уже на завершающей стадии), что ты и бы подобные тебе не использовали где не попадя. Или если и использовали то под каким нибудь другим именем, не пускали тень на проработанную технологию к которой ты к слову не имеешь никакого отношения.
#43 by romix
имхо вы жжоте. Чел выложил свои соображения. Естественно, могут быть ошибки. Вставлю свои 5 копеек в тему блокировок:
#44 by МуМу2
Я Матрейю узнаю уже по почерку. Спорить с ним судя по всему бесполезно. :) А ошибки нужно свои просто уметь признавать, в этом ничего нет зазорного.
#45 by Волшебник
"Ошибки нужно не признавать. Их нужно смывать. Кровью!" (с) к/ф "Кавказская пленница"
#46 by romix
А вообще надо блокировки-то снимать? Имхо это может быть опасным в любой реализации... Ну сохраняется документ лишние 5 сек., ну и что? Все равно же его заполняют (вводят вручную) не 5 сек, а неск. минут. Если же фоново кто-то что-то перепроводит, то он может делать паузы (как в ). Если перепроводится большой регламентный документ, то имхо ничто не мешает проводить его несколькими транзакциями - ведь есть же режим допроведения...
#47 by romix
(+46) Есть еще идея: логику работы модуля проведения (когда он формирует таблицы) вынести в ert или в процедуру гл. модуля. Если в обработчик проведения передается параметр, то он юзает готовые (уже просчитанные) таблицы, а если нет - то он сам вызывает процедуру (ert) для их подготовки, и опять же юзает.
#48 by softpoint8
:) С учетом блокировочных механизмов разрабатывать приложение сложнее но
#49 by softpoint8
соравлось... но я не сказал бы что это опасней. Просто нужно понимать внутренние механизмы. Это все равно что сказать что разрабатывать ИТ системы опасно т.к. могут быть ошибки. Я проводил исследования на эти и другие темы производительности. Могу сказать наверняка что если выстроить(в большинстве своем , бывают конечно и исключения) операции в очередь и выполнять их последовательно то они будут выполнятся дольше чем если их выполнять параллельно. Такова специфика MSSQL. Если будет очень интересно то могу обосновать. Вратце это связано с тем что некоторые процессы могут выполнятся более эффективно засчет того что различные ресурсы могут обслуживаться паралельно. Например одна операцуия будеит в памяти обсчитывать а другая с диском - но это конечно слишком упрщенно.  Проще что бы в этомубедится прогнать тесты. Я их уже проводил.
#50 by Парижская фанера
Узнаю Сами Знаете Кого...
#51 by HIDDEN MESSAGE
#52 by romix
Да, будет быстрее. Я просто рассматриваю возможные другие решения - я не мега-специалист в SQL, и хочу попроще. Вот прочитал и задумываюсь, а нельзя ли сделать так, чтобы, когда два юзера одновременно пытаются проводить, второй вставал в очередь. Сигнальные файлы .LCK в ПриЗаписи что ли создавать, а по окончанию транзакции проведения (например, в обработчики события) их закрывать и стирать? Первый юзер - 1.LCK Первый провелся - в папке файлы 2.LCK, 3.LCK. Четвертый юзер - 4.LCK (ждет удаления файлов с меньшими номерами, только потом сам проводится). и т.д. Если файлов LCK в папке нет, то нумерация опять с 1. Юзерам можно наглядно показывать очередь проведения в строке состояния... Кто-нибудь из мега-спецов так делал? В чем могут быть подводные камни?
#53 by Парижская фанера
Как аварийный отвал юзверя отслеживать будешь? Допустим юзер 1 занял таблицу и скоропостично умер - отвалился семент сети в котором он находится.
#54 by romix
(+52) Или может справочник лучше юзать ... Внутри транзакции проведения потребуется некий Watchdog Timer, чтобы если юзер завис (например, комп выключился), то он всех не подвешивал, а благополучно был выкинут из очереди как зависший.
#55 by romix
Уже ответил в на твою мысль - я не ТелепатБот, но учусь. :-)
#56 by MMF
изобрел велосипед с квадратными колесами. И что будет если юзер 1 создал файл блокировки и завис? Или у него ошибка внутри ПриЗаписи? Или сеть оборвалась/сервер перегрузился после создания файла блокировки? Или два юзера одновременно считали последний номер блокировки (допустим 3) и создают файл с номером 4? А как ожидать освобождения очереди - крутить цикл или показывать окошко с таймаутом 1 секунда? Если уж выстраивать очередь проведения, то надо использовать надежные средства (средствами sql) и делать специальный сеанс 1С - робота для обслуживания очереди.
#57 by HIDDEN MESSAGE
#58 by romix
Я еще тока думаю как лучше. Склоняюсь юзать справочник с очередью, а не файлы (это будет то же самое что SQL-таблица). Для предотвращения зависаний юзать схему WatchDog'а, когда блокирующий очередь клиент должен постоянно давать знать, что он жив.
#59 by Парижская фанера
Чего-то слабо мне верится... ИМХО слабенькие штатные средства у 1С для таких вещей. На основе чего можно сделать WatchDog из штатных кубиков?
#60 by MMF
Средствами 1С можно, конечно, на основе справочника соорудить классическую схему двухфазного коммита (2PC) только каличновасто будет все-равно, ИМХО.
#61 by romix
Я подумал, а со справочником-то подстава. Счетчик WatchDog'а надо будет при длительном проведении обновлять, а справочник в модуле проведения не обновишь, пока весь док не проведется... Вот думаю может ВК забабахать, которая обращается по TCP к некоему серверу с роботом, как говорит MMF. Робот должен принимать входящие соединения, и последовательно разрешать каждому из них проводиться. Если робот недоступен/заглючил, то все остается по старому.
#62 by romix
(+61) Т.е. открывать сокет в ПриЗаписи, ждать разрешения (как самолеты ждут разрешения на посадку), в ОбработкаПроведения слать роботу признаки, что "ведется проведение". А при окончании проведения закрывать сокет.
#63 by Парижская фанера
Гм. Тогда еще наверное надо устанавливать приоритетность/параллельносить для нескольких потоков?
#64 by romix
Да нет, все в один поток (последовательно) будет проводиться... Как кабинка в сортир в самолете. Если кто-то долго ее занимает, и не подает признаков жизни, то его оттуда выкидывать. :-)
#65 by Парижская фанера
LOL! >>Да нет, все в один поток (последовательно) будет проводиться А надо ли? Некоторые види документов вообще не пересекаются, используют разные таблицы для записи. Приоритетностью тоже управлять надо - "удельный вес" клиента/документа в системе различен.
#66 by Парижская фанера
Т.о. ключевой момент - реализация сервера с роботом. Который управляет потоками и ведет учет транзакций. Нечто вроде центра управления взлета/посадки, раз уж мы на самолеты как на модель смотрим?
#67 by MMF
я говорил не об этом. Есть сеанс в 1С юзера Робот. Его задача - проводить поставленные на проведение в очередь документы. Документ при записи ставится в эту очередь. Юзер колотит следующий документ. Робот проводит документ. Юзер по обработке ожидания видит, что его запрос на проведение выполнен и счастливо улыбается. Реализация очереди - зависит от фантазии, описанное было использовано на ДБФ-ой базе с помощью АДО+Fb. Кстати, это все оффтопик :-)
#68 by romix
Ну второй поток может быть, когда нибудь... :-) Я пока хочу с одним-то разобраться, чтобы у юзеров хотя бы "ахтунговое" сообщение про транзакцию не выскакивало...
#69 by MMF
ужас какой-то... С сокетами не так уж просто все, вспомни хотя бы про терминальный режим :-)
#70 by Ильмар
68. Достаточно выполнить все шаги моей статьи... и забыть про ожидания транзакции.
#71 by romix
Ну да. Образчик можно нарыть многопоточного TCP-сервера. Мне надо тока лень превозмочь, и прекратить чатиться в форуме.  :-) Это кстати еще один вариант... Я его где-то видел. Возможный недостаток - товар может списан синхронно 2 юзерами. Хотя он хороший. Почему ужас? Вполне учебный пример. Ты своим клиентам уже это ставишь?
#72 by MMF
правда? И никогда не будет ожидания захвата таблицы журнала документов?
#73 by MMF
ты сначала попробуй написать, а потом возвращайся, обсудим :-) Кстати, стандартные компоненты вполне многопоточны, хоть indy, хоть TServerSocket.
#74 by Ильмар
71. Давно. 72. Будет, но значительно реже.
#75 by MMF
обманываешь, Виталик... ай-я-яй нехорошо
#76 by Ильмар
Никакого обмана... Рассмотрен лишь первый шаг, он действительно не убирет ожидания блокировки. Все остальное в последующих шагах, если мне не надоест агрессивность участников.
#77 by МуМу2
То 70. Ну , врунишка.:) Сам то хоть веришь в то что говоришь? Я сделаю то что ты говоришь в статье и сходу смоделирую 5-10 ситуаций кгда будут блокировки. А также еще 3-4 ситуации  когда нарушатся будет целостность данных. Если бы ты был человеком последовательным я бы даже с тобой поспорил.Ты смог бы удовлетварить свое чувство любопытства а я получить за это небольшую денежную компенсацию.
#78 by Ильмар
77. для тех, кто в танке, статья только началась. Рассмотрен самый первый шаг. Да, могу поспорить, что коллизий не будет при любых штатных методах использования 1с.
#79 by 12345
зря ругаете. Уже одно отключение отборов даст существенную вожделенную оптимизацию) А вот польза от остального сомнительна, ну и ессно, деадлоки (особенно при проведении документа одного вида) никуда не денутся в любом случае.
#80 by Ильмар
79. деадлоков не будет, если выполнить все шаги... Но я их еще не писал. Только думаю о целесообразности делиться знаниями.
#81 by orefkov
Вспоминается децкий анекдот, о самоучителе по прыжкам с парашютом, с продолжением в следующем номере.
#82 by Ильмар
81. По крайней мере мой самоучитель более безопасен и более грамотен, чем самоучитель по  1с++
#83 by Ильмар
+82. Упрек не в сторону компоненты (она хороша), а в сторону хелпа.
#84 by МуМу
Вспоминается анекдот. Сидит мужик и медитирует - -Я не перну , я не перну, я не перну. Короче не удержался - пернул. сидит дальше и бормочет -Это не я,это не я, это не я :) То Матрейя. Хоть десять раз повтори что все будет отлично по тем данным я с позиции моего опыта вижу что будет все плохо- очень плохо. Участвую в бессмысленном диалоге с тобой только для того что бы новички не поддавались на убеждения и не запускали у себя подобные вещи - приведет это к плачевным последствиям. Я в отличии от тебя это могу достаточно подробно аргументировать , что впрочем я и делал ранее.(просто поиском поищу по инету)   Если бы все было так просто как ты описываешь - я бы сам у тебя купил бы. На практике нужно обладать достаточно глубокими знаниями что бы без последствий править структуру 1С. Рецепт статей от Матрейи = Взять несколько выдержек с ИТС, тщательно перемешать с выдержками из других статей, добавить кусками не своих скриптов , плюс добавить несколько своих ничем не проверенных идей и на конец тупо твердить на всех форумах что все круто. Виталик у меня к тебе вопрос, ты  понимешь формальную логику? Если да, то веди себя более конструктивно. Я готов спорить по конкретным техническим вопросам если они будут конструктивные и логичные. (предпологаю что наш упрямый друг опять напишет что то вроде - Я крут а ты лох. :) аргументацию своей крутизны как всегда не приведеть.)
#85 by Ильмар
Му-му, хватит бреда. Реально ответь на мои вопросы. Если у тебя будут технические вопросы - тоже отвечу.
#86 by МуМу
То 85. Приведи вопросы. Повтори их пожалуйста еще раз отдельно в новом посте.
#87 by Ильмар
86. Сначала ты написал кучу бреда, а теперь мне еще искать свои вопросы? Хочешь дискуссий - найдешь. Или напиши их на нью-Территории 1с, там ветка еще не захламлена.
#88 by NS
Мне интересно - а зачем вообще в 7,7 убирать блокировки? Это похоже на тюнинг ушастого запорожца. И блокировки можно убирать другими способами. Способами встроенного языка (например - проведение и подготовка проводок/движений регистра в модуле формы, ввод документов/справочников в обработках и т.д.)
#89 by АЛьФ
Бесполезная ветка.
#90 by NS
Точно, в базу знаний её.
#91 by МуМу
То 87. Опять врунишка обманываешь. Возьми и поиском пробегись по символу "?" Из вопросов у тебя только один пост " Причем здесь ToySQL?" - адресованный не ко мне.(это займет не более минуты) Еще раз спрашиваю , ты законы формальной логики понимаешь?
#92 by Ильмар
Ветка, думаю, очень полезная. 88. Как раз таки вместо доков юзать справочники - это и есть тюнинг запорожца. Я же веду речь об оптимизации. 91. Мне не приятно вести с тобой беседу. оставь меня в покое. Я не люблю спорить о пустом с не очень хорошими специалистами.
#93 by АЛьФ
2 Естественно тебе неприятно с ним спорить, т.к. у тебя недостаточен объем знаний для этого спора. А на одном гоноре с МуМу не поспоришь.
#94 by Ильмар
93. Кто бы говорил о знаниях...
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С