Z1 писал(а) 07. Ноября 2008 :: 06:30:


И что ты предлагаешь?

Z1 писал(а) 07. Ноября 2008 :: 06:37:


Вроде в какой то из последних версий 8 анонсировалась фича по поводу того что переписываются только те движения которые реально изменились, правда кто то говорил что реально не работает. Сам не проверял врать не буду. Вопрос в том как ты собираешся проверять что изменилось, а что нет? И сколько на этом можно выиграть выиграешь.

Можно отключить автоматическое удаление движений и всегда допроводить документ по измененым строкам ТЧ. Флажок что строка проведена можно устанавливать при проведении и сбрасывать при редактировании строки.

Z1 писал(а) 07. Ноября 2008 :: 10:11:

Да, можно, если юзать плагин Опенконф с прямым доступом, например, Телепат, Визуал1С++.
Возможно - подразумевается, что возможно внутри плагина

рефакторинг xp.Сделал исходя из предположения
что практически всегда период = Месяц
для _1sp_GetBeginOfPeriod М поставил первым в IF

Create procedure _1sp_GetNextPeriod(@BaseDate DATETIME, @Period CHAR(1), @NewDate DATETIME OUTPUT) AS

SET NOCOUNT ON
SET DATEFIRST 1
DECLARE @BeginOfPeriod datetime
DECLARE @day integer

IF @Period='M' BEGIN
    SELECT @NewDate = DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BaseDate), '1753-02-01')
    RETURN
END


EXECUTE _1sp_GetBeginOfPeriod @BaseDate, @Period, @BeginOfPeriod OUTPUT
IF @Period='D'
    SELECT @NewDate=DATEADD(dd, 1,  @BeginOfPeriod)
ELSE IF @Period='W'
    SELECT @NewDate=DATEADD(wk, 1,  @BeginOfPeriod)
ELSE IF @Period='M'
    SELECT @NewDate=DATEADD(mm, 1,  @BeginOfPeriod)
ELSE IF @Period='Q'
    SELECT @NewDate=DATEADD(qq, 1,  @BeginOfPeriod)
ELSE IF @Period='Y'
    SELECT @NewDate=DATEADD(yy, 1,  @BeginOfPeriod)
ELSE IF @Period='T' BEGIN
    SELECT @day=DATEPART(dd, @BeginOfPeriod)
    IF @day>15 SELECT @NewDate=DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BeginOfPeriod), '1753-02-01')
    ELSE	 SELECT @NewDate=DATEADD(dd, 15, @BeginOfPeriod)
END
ELSE IF @Period='C' BEGIN
    SELECT @day=DATEPART(dd, @BeginOfPeriod)
    IF @day>20 SELECT @NewDate=DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BeginOfPeriod), '1753-02-01')
    ELSE	 SELECT @NewDate=DATEADD(dd, 10, @BeginOfPeriod)
END
ELSE IF @Period='F' BEGIN
    SELECT @day=DATEPART(dd, @BeginOfPeriod)
    IF @day>25 SELECT @NewDate=DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BeginOfPeriod), '1753-02-01')
    ELSE	 SELECT @NewDate=DATEADD(dd, 5,  @BeginOfPeriod)
END
ELSE SELECT @NewDate=CONVERT(datetime, '1753-01-01')
GO


Create procedure _1sp_GetBeginOfPeriod(@BaseDate DATETIME, @Period CHAR(1), @NewDate DATETIME OUTPUT) AS

SET NOCOUNT ON
SET DATEFIRST 1
DECLARE @Day int
IF @Period='M'
    SELECT @NewDate=DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BaseDate), '1753-01-01')
ELSE  IF @Period='D'
    SELECT @NewDate=@BaseDate
ELSE IF @Period='W'
    SELECT @NewDate=DATEADD(dd, -DATEPART(dw, @BaseDate)+1, @BaseDate)
ELSE IF @Period='Q'
    SELECT @NewDate=DATEADD(qq, DATEDIFF(qq, '1753-01-01', @BaseDate), '1753-01-01')
ELSE IF @Period='Y'
    SELECT @NewDate=DATEADD(yy, DATEDIFF(yy, '1753-01-01', @BaseDate), '1753-01-01')
ELSE IF @Period='T'
    BEGIN
	    SELECT @Day=DATEPART(dd, @BaseDate )
	    IF @Day>15 SELECT @Day=15
	    ELSE	 SELECT @Day=0
	    SELECT @NewDate=DATEADD(dd, @Day, DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BaseDate), '1753-01-01'))
    END
ELSE IF @Period='C'
    BEGIN
	    SELECT @Day=DATEPART(dd, @BaseDate )
	    IF	@Day>20  SELECT @Day=20
	    ELSE IF @Day>10  SELECT @Day=10
		ELSE		 SELECT @Day=0
	  SELECT @NewDate=DATEADD(dd, @Day, DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BaseDate), '1753-01-01'))
    END
ELSE IF @Period='F'
    BEGIN
	  SELECT @Day=DATEPART(dd, @BaseDate )
	  IF	@Day>25 SELECT @Day=25
	  ELSE IF @Day>20 SELECT @Day=20
	  ELSE IF @Day>15 SELECT @Day=15
	  ELSE IF @Day>10 SELECT @Day=10
	  ELSE IF @Day>5  SELECT @Day=5
	  ELSE		SELECT @Day=0
	  SELECT @NewDate=DATEADD(dd, @Day, DATEADD(mm, DATEDIFF(mm, '1753-01-01', @BaseDate), '1753-01-01'))
    END
ELSE SELECT @NewDate=CONVERT(datetime, '1753-01-01')
GO
 

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

Короче речь идет о рефакоринге проведения регистров
Как маленький пример смотрите xp изменения периодов пост 9.
Это изменение даст выигрыш везде во всех конфигурациях.
Рефакторинг проведения - может назвать "Прямое проведение" ( по аналогии с прямыми запросами)
даст огромный выигрыш в скорости и при этом не меняется ни одной строки в исходной конфигурации.
Изменения затрагивают только xp.

Честно говоря ниасилел где будет огромный выигрыш
Вот проводить одну строку вместо 200 - дело другое...
Можно пояснить для тупых когда взлетит поподробнее?

Про что статья то?

all ну неужели вы не видете фишку ?
А если сказать так - это будет лучше чем гибкие блокировки

Nick писал(а) 13. Ноября 2008 :: 10:04:

почему ??? ТЕстовая база работает уже с понедельника.
Сейчас думаю как все это переносить в рабочую базу.
Также думаю над оптимизацией того что есть. Но по некоторым вещам не хватает знаний.
Ближайшая цель убрать курсоры в хп ra...

база сейчас тестовая копия реальной.
Все основные действия пользователей работают правильно.
Чтобы перевести на реальную базу Цитата:

Ключевое слово : другой Алгоритм проведения.
лучше чем тот который есть сейчас, а реализовать алгоритм можно так как есть точки доступа в виде xp.

сейчас выложу в ветку

Пролог

Все началось с того, что перевалив какой то предел 1с стал «Тормозить».
Возникают пиковые ситуации все процессы становяться в очередь на проведение и все :  1с "умирает". Очередь по блокировкам wait доходит до 5-10 и все alles.
Отдельно работающие пользователи все ок.
Стал думать о гибких блокировках. Прочитал о существующих решениях.
Полез внутрь хп. Сначала нашел несоответствие по переполнению регистра 99999
Ветка на 1с++ (  http://www.1cpp.ru/forum/YaBB.pl?num=1225518509 )
После этого почитал умные книжки по sql и написал свою реализацию гибких блокировок.
Стал рисовать картинки на бумаге. Получалась довольно невзрачная картина либо
возможны взаимные блокировки строк таблиц базы,
либо стоимость блокировок становилась огромной и решение становилось бы
сопоставимым с тем какое есть сейчас.
После этого стал «копать» еще глубже и разбираться как оно все работает.
В частности как работает 1с с регистрами.

Чтобы понять недостатки вышеописанного алгоритма  рассмотрим несколько примеров :

Пример №1.
Пусть есть проведенный документ Приходная Накладная от 10.01.2008 ( т.а стоит на 31.12.2008) Скажем 200 строк с разными товарами.
В этом документе изменяем примечание и сохраняем и перепроводим документ
Что при этом будет происходить
Начинает работать ОчиститьДвижения()
1.Для каждого движения ( каждой строки т.к. у нас на одну строку одно движение)
Для всеx периодов уменьшаем значение таблицы  RG
2. Для данного документа очищается все RA ( как вызывается метод ) не знаю.
Для каждой строки в МодулеПроведения выполняется ВыполнитьПриход
при этом добавляется строка в таблицу ra
и для всех периодов увеличиваем значение таблицы RG

Проделана огромная работа, а результат остался прежний.
(Для таблицы RG имеем изменено строк = 12*200*2  = 4800 update)
В идеале не надо вообще ничего делать в RG


Пример №2
Пусть есть непроведенная Приходная накладная от 12.01.2008 и в ней 10 одинаковых строк
Тов1,Склад1,15 (15 колво)
Что происходит при Записи и проведении этого документа.
Начинает работать ОчиститьДвижения()т.к. движений нет ничего не очищием.
Для каждой строки в МодулеПроведения выполняется ВыполнитьПриход
при этом добавляется строка в таблицу ra
и для всех периодов( от 01.01.2008 до 01.12.2008 ) увеличиваем значение таблицы RG на 15.

В результате имеем для таблицы RG выполнилось для каждого периода
10 одинаковых операций
увеличиваем значение таблицы RG на 15.
(всего операций по изменению 12 * 10 = 120 изменений )
В идеале хотелось иметь бы одну операцию для каждого периода
увеличиваем значение таблицы RG на 150  ( т.е. всего 12 операций)

Пример №3
берем проведенный документ из примера 2 и просто делаем отмену проведения

Начинает работать ОчиститьДвижения()
1.Для каждого движения ( у нас 10 одинаковых движений)
Для всеx периодов( у нас их 12 )
уменьшаем значение таблицы  RG на 15
(всего операций по изменению 12 * 10 = 120 изменений )

В идеале хотелось бы одну операцию для каждого периода
уменьшить значение таблицы RG на 150  ( т.е. всего 12 операций)


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

Рассмотрим те же самые примеры 1-3 для нового алгоритма.

Пример №1
Начинает работать ОчиститьДвижения()
1.Для каждого движения ( каждой строки т.к. у нас на одну строку одно движение)
копируем эту строку в Х_RG.

2. Для данного документа очищается все.

3. Для каждой строки в МодулеПроведения выполняется ВыполнитьПриход
при этом добавляется строка в таблицу ra

4 При вызове метода метод СохранитьВсеДвижения()
После свертки таблиц получаем таблицу с нулевым числом строк
Таблицу RG не изменяем совсем.

Пример №2.
1.Начинает работать ОчиститьДвижения() т.к. движений нет ничего не очищием.
2.Для каждой строки в МодулеПроведения выполняется ВыполнитьПриход
при этом добавляется строка в таблицу ra
4 При вызове метода метод СохранитьВсеДвижения()
сворачиваем строки получаем одну строку
( сворачиваем 0 строк из x_rg  и 10 строк из ra )
товар_1,склад_1,150
для всех периодов изменяем таблицу RG
т.е всего изменений в таблице rg 12* 1 = 12

Пример №3
1.Начинает работать ОчиститьДвижения()
добавляем 10 строк из текущих движений в таблицу x_rg.
2. удаляем движения из ra.
4 При вызове метода метод СохранитьВсеДвижения() из Модуля Отмена Проведения()
сворачиваем строки получаем одну строку
( сворачиваем 10 строк из x_rg  и 0 строк из ra )
товар_1,склад_1,-150
для всех периодов изменяем таблицу RG
т.е всего изменений в таблице rg 12* 1 = 12

небольшое упражнение Пример №4
Есть проведенный документ скажем за 10.01.2008.
В документе произвольное количество строк скажем 5 000.
Мы меняем только одну строку.
Тогда расписав все  вышеизложенные действия ( предоставляется сделать это читателю самостоятельно ) вы получите Всего 12 изменений в таблице rg.
Замечание упражнение 4 предполагает что не менялись признаки косвенного проведения т.е. не менялся алгоритм проведения или при изменении статуса товара могут генериться другие движения)

Z1 писал(а) 13. Ноября 2008 :: 10:29:


, покажешь?

Статью прочитал. Судя по ней, за решение пятерка. Но не понятно к чему сравнение с "гибкими блокировками". Твое решение - это "мягкое", а ГБ - это "теплое".

Суть ГБ от софтпоинта в том что теоретически в один момент времени может проводиться более одного документа. И всё.
Твое решение не о том.

Цитата:


Даже если обе будут двигать один и тот же товар?

Z1 писал(а) 13. Ноября 2008 :: 11:55:

Хм. Но намеков на это я в статье не увидел.

Z1 писал(а) 13. Ноября 2008 :: 12:09:


А если нужен тогда как?

Nick писал(а) 13. Ноября 2008 :: 12:17:

Наверное также как и в любой другой системе  ставим свою блокировку
считаем и двигаемся дальше.
Еще теоретически проверку  остатков я думаю можно поставить в конце при Записи ( естественно со своей блокировкой )
Плюс будет в том что это действие не будет происходить в дорогостоящей операции транзакция.

trad писал(а) 13. Ноября 2008 :: 12:28:

да снял все блокировки со всех кроме user и не помню как называется которая выдает новые id.

А на конкретном документе и так болтается файловай блокировка.

Z1 писал(а) 13. Ноября 2008 :: 12:30:

Тогда об этом нужно было рассказать перед сравниванием с ГБ. И заодно рассказать как правильно вручную блокировать объекты БД что бы не начитать всякий мусор и не влететь на дедлоки.

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

А зачем при УРБД тащить ТА далеко вперед (на несколько периодов), что за религия?

DmitrO писал(а) 13. Ноября 2008 :: 12:51:

нет x_rg это дельты rg и структура у нее как у rg .
это просто отложенные в сторогку дельты


почему так назвал потому что вседга обычно использую такую приставку.
так сложилость исторически в каком то релизе 1с в стандартном запросе текст
Товар = Документ.Расхобная.Товар не работал
а текст
Х_Товар = Документ.Расхобная.Товар  работал
с тех пор я этот Х_ ставлю автоматически.

DmitrO писал(а) 13. Ноября 2008 :: 13:02:

да
+ еще в моей реализации столбец @@spid

Завтра , седня мне еще поездить надо.

Ога, только восстановление последовательности эффективнее делать со сдвигом ТА.

DmitrO писал(а) 13. Ноября 2008 :: 12:47:


вопрос по ТА не видел.
TA в будущем по нескольким причинам

1. Специфика учета.Есть док Планируемые затраты.
Когда затраты планируют документ создают.
Когда утверждают документ проводят.
Диапозон дат документа весь текущий год.

2. в УРБД TA не переносится из одной ПБ в другую и когда
формируют остатки в разных ПБ с пустой датой (на TA ) остатки разные,
но при этом матерьяльная ведомость одинаковая.
Объяснить ситуацию пользователям невозможно да и не нужно.

3. Продвинутые пользователи которые работают в бух программе
после бухгалтерии с трудом понимают что такое за зверь TA и
просят настроить как в бухгалтерии они "думают" налоговыми периодами.
( и вообще в бухгалтерии сделано более логично решении о смене периода принимает человек,
а тут программа молча сама что-то пересчитывает назначает  ТА не понятное).

4. C точки зрения реализации программы TA может постоянно меняться причем как вперед так и назад при отмене этого документа при этом 1cv77.exe должен
постоянно блокировать и разблокировать связанные с этим ресурсы и пересчитывать значения в периоде на ТА

5. Если бы был сделан период TA кратный месяц ( ну другие периоды аналогично )
то тогда внутри программы ( в тех же rg ) вместо даты DATATIME
можно использовать номер INT начиная с 01.01.1753.
Тогда работа всей программы 1с теоретически будет быстрее.

Пока писал 5 придумал, что если завести общий реквизит = номер месяц документа
и это поле проиндексировать в _1sjornl тогда в запросах 1с++ кратным месяцу
можно будет писать between int_нач_дата AND int_кон_дата что будет работать  еще быстрее чем как сейчас.

Я вот не могу понять чем ты умаевыешся я о Z1.  

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

Сделал бы это лучше:

Есть возможность вообще паралельно проводить документы, тоисть внедрение своих блокировок, это раз!
Во-вторых можно все переписать на 1С++ и не будет никаких тормозов!

Насчет блокировок не знаю как они в 1С++ но на ToySQL есть такая возможность, хотя документация по этому была платной, попытайся найти что-то на его ресурсах:
http://forum.1csql.ru/
а также тут:
http://1csql.ru/index.html

Цитата:

сомневаюсь, так как сравнение идет по Кластерному индексу. Проверю точно отпишусь.
Цитата:

не подскажешь - где тут преобразование? Вроде Date_Time_Iddoc имеет тип char(23)