РегистрСведений или РегистрНакопления? #663677

у клиента простенька база. справочник покупателей и один документ заказ. Периодически он заказы чистит. У покупателя есть телефон. вобщем надо сделать регистр(измерение: телефон, ресурс:сумма) на котором копятся суммы. ну и общей суммой потом определяются скидки этому покупателю(бронзовый, золотой, серебрянный) Основная проблема это то что фискалка(заказы) периодически подчищаются. но суммы надо сохранять. Ну и историю из эксель с прошлых архивом чтобы можно было подтянуть.  Можноли тут использовать регистр сведений вместо регистра накопления? ну чтобы потом расчитывать скидки клиентам, взять там запросом по всем телефонам сгруппировать и раз в день выставлять уровни скидок в другом регистре.

Не чистите заказы, храните обороты в оборотном регистре накопления.

100%

а РС совсем не подойдет?

Голову не сломаете, делать РС не подчиненный регистратору, но при этом несущий логику оборонного регистра накопления?

Оборотного, конечно.

не. не сломаем. вообщем просто интересует насколько тормозно будет обрабатываться запрос по РС. и запросная функция СУММА будет применимам к числовому ресурсу РС? я просто до базы еще не добрался чтобы проверить.

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

>>  насколько тормозно... Всё зависит от объема данных. РН имеет таблицы итогов, позволяющие быстро получать суммы оборотов по измерениям. У РС таких таблиц итогов нет. Соответсвенно при получении оборотов за год система будет считать сумму по всем записям. На относительно небольших объемах данных разницы вообще не будет. Только всё равно не понимаю нафига вам РС. Чистите базу, если вам так хочется (хотя нафиг это надо я не понимаю). При чистке заказов сворачивайте записи по РН. Регистратором сделайте какой-нибудь служебный документ (например, как в типовых - КорректировкаЗаписейРегистров).

да мне по периодам итоги и не нужны. меня вообще интересует только итог по одному измерению за весь период.

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

>> по периодам итоги и не нужны Тем более! Раз не нужны данные за месяц/год/квартал, значит нужны итоги за весь период ведения базы. Теперь представь: База ведется пять лет. Записей регистра (неважно сведений или накопления) миллионы. Чтобы получить итоги по РС система будет выбирать из миллиона записей и суммировать. Чтобы получить итоги по РН система проссумирует данные из таблиц итогов (а не из таблицы первичных записей), где записей на порядок (а может и на несколько порядков) меньше.

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

РН с признаком "Не удалять движения" В этом случае получаете все преимущества РН и документы заказов можно удалять.

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

и записи РН будут жить без регистратора?

Еще раз для тех, кто в танке: Величина тормозов зависит от объемов данных. Я уже писал в : "На относительно небольших объемах данных разницы вообще НЕ БУДЕТ". Однако если у вас, например, десятки тысячи заказчиков и сотни тысяч заказов в год, то на РС получите весьма заметные тормоза. PS. Но вообще мне сама постановка непонятна. Нафига свёртка вообще нужна? Нафига заморачиваться с РС, если есть РН? Может вы в армии служите, где круглое носят, а квадратное катят? А нафига вообще регистры и документы - делайте всё на справочниках! Круто, удобно, просто!

Они там не только в танке - они ещё и скидку рассчитывают по этому регистру - вопрос - где они будут хранить результат расчёта - мне кажется, что регистр сведений с ресурсами "сумма" и "скидка" наиболее удачно для этого подходит, а вот накопления лучше хранить в регистре накоплений - то есть два регистра!

А нафиг нужно измерение телефон? Имхо, независимый РС с измерением клиент и ресурсом сумма. При проведении документы тупо изменяют ресурс сумма у единственной записи по клиенту в РС. Надо еще грамотно прописать распроведение документа и все.

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

нужен остаток суммы или сумма за период?

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

сумма по всем движениям. периодически РС независимый от регистратора в полне мне кажется подходит. 1000 телефонов в день. 360000 в год.

храни движения в РН, размер скидки в РС. У документа реквизит "заказ закрыт" если закрыт то не показывать в списке. Все довольны. Хранить движения без регистратора плохо т.к. не найдешь концов, городить подмену регистратора и удаление заказов тоже не комильфо т.к. нафиг не надо ибо места в базе документ без движений практически не занимает(редкие исключения есть). Получение агрегатов с РС это совсем не хорошо т.к. это будет слишком ресурсоемко для базы.

Будут. Им пофиг. Просто при просмотре РН будет выводиться "Объект не найден" При необходимости можно по полям "Период" и "Телефон" связать с базой заказов в Экселе. Но вообще-то правильнее заказы не удалять.

В какой-то отраслевке видел, что пробег автомобиля хранили в РС. Просто последнее значение пробега пишется в РС. Потом по срезу это значение вытаскивается. Такой РС можно спокойно чистить.

РС не имеет отдельной таблицы под срез последних. Данные будут браться из физ таблицы соединением.

Не поняла. Скидка для клиента или для телефона? Какая разница, с какого телефона он звонил? Главное, кто звонил.

прикольно.

Глупо, а не прикольно. Я на 100% уверен, что "очистка заказов" - блажь заказчика, который со своим десятков заказов в день экономит 10 Мб. Сделайте ему в базе обработку, которая сгенерирует 1 000 000 заказов, и покажите размер базы в этой вашей файловой крякнутой 8-ке. 100 Мб?

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

А как установить признак "Не удалять движения" у РН?

У документа на закладке Движения, который пишет в регистр, не у РН. Тогда при удалении этого документа движения по нему не будут удаляться.

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

400*360=146тыс заказов в год. 1,5млн за 10 лет. Особой необходимости в удалении заказов не вижу. Обычный РН с измерением Клиент и Ресурсом сумма. Причем "Клиент" - ссылка на справочник. Для справочника еще можно Быстрый выбор по реквизиту "Телефон". Т.е. оператор вводит телефон и по нему при наличии данных подставляется Клиент. Если данных об этом клиенте нет, то при сохранении документа автоматом добавляется новый. Т.е. поиск по телефону, но хранение данных по клиенту. И унифицировать ввод телефона (с пробелами, тире, скобками или без, с кодом страны или без)

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

Только что попробовал: при настройке документа на вкладке "Движения: Удаление движений - Не удалять автоматически", движения из РН не удаляются при пометке документа на удаление. Однако при удалении документа (через удаление помеченных объектов) - у меня из РН удалились и движения сделанные этим документом. Похоже что-то не так делаю. Как воспроизвести Ваш пример?

а можешь с Shift+Del на проведенном документе попробовать, или .удалить(непосредственно)(или как там)? просто под рукой нет ничего чтобы проверить : )

Попробовала. По умолчанию действительно удаляет. Нужно еще дописать в модуле документа в процедуре "ПередУдаление" ОбменДанными.Загрузка = Истина; В этом случае в 8.2 УФ при Shift+del и при удалении помеченных не удаляет. Остается движения с тексом "Объект не найден" 100000 записей это мелочь. Даже для файловой версии. Нужно смотреть не на количество записей, а на структуру: 1. Индексы по наиболее частым запросам 2. Все связи в таблицах только по ссылочным полям (не по строковым) 3. Корректность связей запросов. 4. Для виртуальных таблиц условия именно при выборе данных до построения таблицы. и т.д.

ну это ежу понятно ;) мопед не мой. приходится работать с тем что есть.

Значит оборотный РН и агрегат с двумя полями (клиент+оборот) без учета периода. И пофиг, сколько данных в базе.

Спасибо! Получилось. Только при похоже не важно, что стоит в документе на вкладке Движения. При настройке документа "Удаление движений - Удалять автоматически" по Shift+Del у меня движения в РН тоже остались со значением в поле Регистратор "Объект не найден".

нету регистратора зачем вообще тогда РН? Храни в одной строке РС и меняй сколько душе угодно, но это утопия...