Очередной бред про партионный учет. #160443

Господа, я вот в порядке бреда "родил" очередную мысль. Всем вам известен алгоритм партионного учета. В классике это делается на регистре остатков. Т.е. есть некий регист, в упрощенном виде: Измерение:Партия => Ресурс:Количество. Для списания получаем все доступные партии поступления, упорядоченные по FIFO и LIFO и списываем с них. Я вот подумал, а будет ли выигрыш, если делать партионный учет на паре регистров сведений. Первый регистр сведений ДоступныеПартии: Измерение:Партия => Ресурсы:ОбщееКоличество, ДоступноеКоличество. Второй регистр сведений СписанныеПартии: Измерения:Партия, ДокументСписания => Ресурсы:Списано. Тогда алгоритм списания будет таким: найти все партии, у которых доступное количество<>0 и дата меньше даты документа списания. Занести списания в регистр СписанныеПартии и уменьшить доступное количество в регистре ДоступныеПартии. Правда, придется еще заниматься и отменой проведения - восстанавливать партии,  но можно все это занести в модуль одного из регистров, тогда будет идти автоматом. Ускорение за счет того, что партии хранятся отдельно и меньше по объему их таблица физически, так же не нужно считать остатки. Что скажете? Больно не бейте.

Тут не бить надо.

А может, о С++ лучше? :-)

а ты что, в партиях уже разбираешься?

Опять?!!!! Волшебник - закрой эту ветку!!!!

Ключевое слово "в порядке бреда"...

Что опять?

Неужели я опять допустил логическую ошипку?

Подарок выбрал?

Пишецца ашипку.

в ветку

(ОЛЛ) А по существу вопроса мнения будут?

Да, будут. Очень актуально для меня ;). А если в доп. регистре хранить партии по которым есть остатки и в запросе указывать их список, ИМХО быстрее будет...

Или я то же самое сказал...

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

Точно не прикалываюсь, только пробовать лениво

Можно вопрос - а зачем?

Опять бред и бредовое обсуждение. Ну сколько можно?!

Проведение - пойдет "на ура". А вот отмена проведения... Подумать надо.

а че отмена? Восстанавливаем партию - переносим ее в регистр доступные и все хокей.

Лажа

Это на будущее

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

Респект

я в сортах *ерьма не люблю разбираться.

а какого ты тогда на мисте делаешь? гыгыгы.. Ладно, народ, в тему дружно, в тему!

Обоснуй

Что?

Свой респект, типа ты чето в гугле по теме нашел? Гонишь ты, чувак!

Ускорение проведения, вот зачем, ясно написано

Зачем его ускорять, когда можно просто не тормозить

А зачем ?

Иногда лучше жевать, чем говорить...

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

Именно так к мертвым и отношусь: либо факты, либо ничего...

Тебя не бесит что в каждой ветке с твоим участием тебя все время пинают?

а какого ускорения планируется достигнуть? 2g, 5g, 20g?

лучше придумайте нормальный механизм авто вытеснения при востановлении кривых последовательностей, я думал, что для этого стоит ввести реквизт, типа НеЗаменятьФиксированно

Для этого нужны не реляционные таблицы, а очереди (сети)

Если наш гени(тали)й  поймет, как по одной цифре (остатку в партии) расссказать все о движении данной партии, тогда он не только ускорит проведение, но и сделает ненужным перепроведение... P.S. только вот гениям этого не дано...

Гений, он и есть Гений...

Давай сделаем так. Ты реализуешь идею в конфу и мы посмотрим результаты. А то на словах в самом деле бред ...

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

Прям таки вижу эту бедную торговую фирму которой реализовали быстрый партионный учет руками одного из гениев...

ну у меня положим, по скорости партионный учет обычный, но позволяет работать задним числом без перепроведения... Штатными методами быстрее все равно не сделаешь... И чего я должен показывать?

Как ты это реализовал?

в таблице списаний ты увидишь всю историю списания по партиям, тупишь, чувак. Во-во, как ты это реализовал. :)

будет время, поковыряюсь на каркасной - ну на той конфе, что экзамены по спецу сдают. Времени нет. А идея хорошая по-моему. :) И сразу видно неправильные партии - отсюда восстановление ГП быстрее.

Изолировать автора.

Начал писать в каркасной конфе... Вроде получаетца

Оно то конечно прикольно но как ты будешь выводить ОСВ по партиях?

Идея такая (на данный момент времени) - для движений по партионке используется обычный регистр накопления (ОСВ будет как обычно). А вот для списания партий - регистр сведений свободные партии. То бишь для списания не нужно будет получать остатки по регистру накопления. Сие дает ускорение.

И кстати, в модуле набора записей регистра накопления привязана автоматическая корректировка регистра сведений по свободным партиям

И большое ускорение?

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

то бишь в классическом партионном алгоритме есть еще резервы для оптимизации. Жаль только, что регистр накопления можно перезаписывать только целиком по регистратору. (В 80 только такой отбор)

Прикинул ... ускорения не заметил, а у тебя как?

Прикинул. Условия одни и те же, структуры таблиц похожи, в чем выйгрыш?

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

Не один хер? В одном случае фильтрует SQL-сервер, у которого мозг достаточно хороший, а в другом - интерпретируемый код, созданный ... к черту подробности :)

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

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

Что-то слишком сложно! Я вашу идей понимаю так: при приходе (ну скажем 10 единиц) выполняем запись в периодический регистр сведений "Доступные Партии" (а какая у него периодичность? Год?): Партия1  10 Потом списываем 5 единиц и вынуждены внести такую запись: Партия1  -5 Т.е. при расходе выпонив функцию СрезПоследних по Партии1 получим 5 единиц. Вроде все нормально, но таким образом мы эмулируем регистр накоплений. Но зачем нам эмулировать регистр накоплений если в 1С уже есть такой замечательный механизм. И думаю остатки по регистру накоплений работаю быстрее чем срез последних в регистре сведений. А тут еще проблема с периодичностью, как быть если период действия регистра закончился (в конце года), а нам нужно списывать с партий которые появились в прошлом периоде? Вообщем, на мой взгляд, идея не очень удачная.

Мне кажеться бред получиться (это примерно тоже если вести партионный учет в переодических элементах для 7.7), тоесть надо будем много чего пересчитывать при проведении документа Резюме выиграешь на чтение проиграешь на записи

А Вы уверены, что правильно себе представляете получение остатков из регистра накопления? Расчетов там ведется очень мало, а если еще нет работы махровым задним числом, то расчетов нет совсем. А вот поиск даных по условиям больше/меньше совсем не легкая процедура при больших объемах данных...

неа... Партия - это документ Структура РС (непериодического) такова Партия,Товар,Дата => Остаток Этот РС заполняется автоматом из РС партий (накопления) Партия, Товар => Количество. Т.е. любое движение по приходу добавляет запись в РС, любое движение по расходу уменьшает соответствующее количество в РС, а если это количество становится равным нулю, то эта строчка удаляется из РС.

Да, при одних и тех же условиях поиск по РС и поиск по РН выдадут один и тот же список (объем данных) - это на вопрос фильтрации, только по РН еще надо остатки посчитать на момент документа.

Фильтрация как раз может работать очень по разному для РС и для РН. А зачем считать остатки на момент документа? Чтобы получить красные остатки на конец месяца?

А что время выборки из регистра сведений производится быстрее чем расчет остатков в регистре накоплений? По моему дольше. Поскольку, если таблицы большие, тогда для отбора (даже по индексу) SQL должн перелопатить кучу данных, а остатки по рег. накоплений программа хранит в промежуточных таблицах, доступ к которым будет осуществлятся быстрее.

фильтрация идет одинаково, ибо измерения одинаковые (все упирается в структуру измерений), а вот остатки надо еще вычислитьна момент документа. ты хоть раз писал партионное списание, хотя бы по ФИФО, что за глупый вопрос?

Писал и не один раз. А вот Ваше сомнение в этом крайне настораживает...

А на какой момент вы берете остатки? Неужели на точку актуальности ;-) Поясните тогда...

Не очень понимаю глупость вопроса разъясни, пожалуйста? Хорошо но в чем тогда выигрыш если: > Да, при одних и тех же условиях поиск по РС и поиск по РН выдадут один и > тот же список (объем данных) - это на вопрос фильтрации, только по РН еще надо > остатки посчитать на момент документа Все равно нужно считать остатки, так зачем нам лазить по регистру сведений? Что то не улавливаю суть идеи

Остатки беру на конец месяца, если вообще их беру при проведении документа. Ведь партии то можно и в конце месяца подобрать регламентым документом.

Не путай специфику своей конторы с общепринятыми нормами. Нам нужны актуальные остатки по партиям - супермаркет. Например, чтобы знать остатки по поставщикам!

имеется ввиду списание партий на текущий момент времени, не откладывая до конца месяца!

В случае РС остатки считать не надо - у нас они уже готовые в РС.

Стоп господа - посыпаю голову пеплом. Эта схема эквивалентна списанию товаров, когда остатки берутся на дату актуальности итогов. :-) Окей... Убедили. Бред, хотя надо над ним подумать.

Тогда как вам другой бред (свеженоворожденный). В справочнике партий Партия=Документ+Товар у каждой партии идет ссылка на следующую партию (цепочка). Тогда списание выполняется так. Выбирается последняя партия, с которой было произведено списание до момента документа (поиск по регистру накопления), с нее досписывается остаток, а потом уже по цепочке идет списание нужного количества. о.

Зачем в супермаркете (для получения указанной информации) партии в онлайне?

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

Имеется ввиду не в онлайне, а например на утро.Но не раз в месяц нам надо знать остатки по поставщикам (то бишь по партиям)

Замечательно вы изорели "Последовательности"! OFF: Ваши идеи напоминают историю с доказательством теоремы Ферма. Тогда куча диллетантов пыталось доказать "на пальца", а в конце концов теорему доказали через много лет и с использованием сложного математического аппарата

он нормально влезет в очередь

над этим надо подумать... :)

Еще раз повторю вопрос - зачем для остатков по поставщикам двигать партии в указанной постановке задачи? и тогда чем это отличается от обычного партионного регистра без сложным связных списков?

чувак, для остатков по поставщикам достаточно обычного ФИФО, я ж уже покаялсся. А вот мысль в была насчет ускорения проведения.

чувак, там и ФИФО лишнее... а в чем ускорение проведения в ?

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

1. А зачем? при партионном на двух регистрах схема Вождя даст тебе искомое - в реале списание количества, в офф-лайне - партии. 2. а если мне не хватает первой партии я снова куда-то лезу и т.д. или ты считаешь, что обход по цепочке будет дешевле, чем получение нужного (с фильтрами) списка партий?

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

1. ну кроме существенной разнице в нагрузке на базу - никакой. ну как скажешь 2. :)) с чего это ты так думаешь? в пределе ты получишь ровно тот-же список, что и мой запрос. Но я дерну базу один раз, а ты будешь ее много-много мелких разиков дергать...

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