Попалась на руки база 77, в которой ведется учет накопительных дисконых карт.

Горе-разработчик завел регистр остатков с двумя измерениями:

"ДисконтраяКарта"
"Документ"

и ресурсом

"Накопление"

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

Понятно, что проблему можно частично решить, переместив "Документ" из измерения в реквизит, но все равно дисконтных карт выдано порядка 100000 тыс, а это значит что каждый месяц при переносе остатков таблица регистра остатоков пухнет на 100000 строк, даже если нет движений; за 10 лет получаем уже приличную таблицу.

Оптимальным кажется использовать регистр оборотов, но не будет тормозить получение накопленной суммы по ДК за 10 лет?

нужно будет перепровести за 10 лет.. не смущает? ))

(0) А Документ зачем???

(0) никогда не задумывался зачем режут базы?
1. да измерение Документ = документ движения = это жесть конечно
2. но регистр оборотов - хз, зависит от того насколько часто нужны данные по скидке
3. 10000 строк в конце каждого месяца - это крохи

Это очень хороший пример когда регистр использовать нельзя.

(4) ???

(3) +1
(0) Если не нужно помнить историю накопления, то можно просто сделать реквизит в ДК и добавлять в него все суммы.

Если в регистр, то так же ничего страшного нет, это такая проблема всех баз - расти. :)

(0) Э-э, заметил и смутился :)

"100000 тыс" - это сколько?

(1) Перепроведу по одному регистру, не страшно.

(2) Видимо есть какой-нить супер-пупер отчет, который используя остаток по регистру, выводит все документы, по которым проходила дисконтная карта.

Регистр оборотов смущает тем, что будет материться тот, кто сворачивать базу потом будет :)

Думаю сделать Регистр оборотов + Реквизиты справочников

(7) 100 тыс конечно :)

(8) В регистре итак заложен документ движения регистра.

(8) Наверное оптимальный вариант. Но только нужно быть осторожным при отмене проведения, если задействовать реквизит в справочнике.

я использовал подчиненный справочник

+(11) У меня похожая схема была в одной из баз, суммы необходимые для расчета держал в реквизитах справочника, но документ по ДК движений не делал, а просто служил хранилищем нужной мне информации.

+(13) Была идея делать движения по регистру, но я так и не увидел причину - зачем?

Подписка

(12) И что было в подчиненном справочнике?
Документ и сумма?
ИМХО выбрать подчиненные и просуммировать и все это в нужный момент по конкретному контрагенту будет достаточно быстро
А если нужен отчет по всем контрагентам? Как оно будет?

(16) информация о покупке: дата и сумма.
Работало без проблем во многих магазинах.
Зачем отчет по все контрагентам?
Сумма нужна только в момент продажи, чтобы определить скидку

(17) Ну я тоже считаю, что это самый правильный и удобный вариант

Примерно аналогичное решение было. Но с другой вариацией. Для анализа продаж - регистр. Фиксация продаж в справочник (не подчиненный).

(16) напрямую очень красиво и быстро будет))