Использование СУБД #588550

Добрый вечер. Есть конфигурация на 1с 8.2, которая работает в файловом режиме (Комп двухъядерный с 2 гб оперативы). В регистр этой конфигурации загружают ежемесячно большое количество информации (около 100 000 строк а на каждые 25000 создается документ), соответственно база начинает раздуваться и тупить. Будет ли эффективней с точки зрения хранения информации и производительности конфигурации поднять на этом же компе СУБД и перевести конфигурацию в клиент-серверный режим работы ?

Сначала описание регистра давай в студию...

<<соответственно база начинает раздуваться и тупить.>> Красиво. Другого не ожидал от автора.

Не придирайтесь к словам. Понятное дело, что не только от этого тупит, а быстро растущий размер базы не устраивает клиента. Но дело вообще не в этом. Меня интересует, какой вариант будет работать более эффективно. Регистр: непериодический, 13 измерений и 5 ресурсов.

Регистр: непериодический, 13 измерений и 5 ресурсов. Да вы программист.

Почему именно 13 измерений и 5 ресурсов? Вот если бы 8 измерений и 10 ресурсов - было бы куда оптимальнее. Количество индексируемых полей лучше подбирать так, чтобы они составляли степень двойки - работать будет быстрее...

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

Если эффективность == скорость для одного клиента, то нет.

<<соответственно баБа начинает раздуваться и тупить.>>

спасибо

Почему бы не создать 1 измерение с MD5-хешем от данных, от которых зависит уникальность строки? MD5 подвержен коллизиям? Если есть такая паранойя - при каждой записи/поиске в регистр и нахождении уже существующей - проверку на равенство каждого из элемента данных. p.s. Когда сильно хочется, но нельзя Тогда немножко можно, но не со мной.

Это не уменьшит объем базы, но уменьшит время записи.

Чьерд! Ты переплюнул меня. *посыпает голову пеплом*

нафея хеш, если в РАУЗ уже предложена схема такого решения?

Кто эти люди? Какие данные? Какой хеш? Вы куда со своими советами? ДАНО: Ежемесячно 100 000 строк данных, 4 документа в месяц (25 000 строк каждый). И регистр независимый, содержит 15 основных параметров и 3 дополнительных. ТРЕБУЕТСЯ ПРЕДОТВРАТИТЬ: быстро растущий размер базы и тупость базы. Это что такое? Поподробнее... Уточнение: Зачем нужен документ? В чем заключается тупость базы? Что делают с данными?

С количеством строк ошибся, их до 1 000 000  =) Документ фиксирует запись данных в базу. (документ можно сделать и по 50 000 строк - не важно). По данным формируют отчеты, печатаю выборки, выставляют счета.   Тупость базы: - чем больше загружаем , тем медленнее формируются отчеты, счета и т.д. - А если подключается по сети еще 1 пользователь - вообще жуть. Всего с базой будут работать 2 пользователя. ( сообщили про 2ого пользователя только что)

Избыточность.

Ну просто жуть, жуть, жуть. - А если подключается по сети еще 1 пользователь - вообще жуть. Всего с базой будут работать 2 пользователя. ( сообщили про 2ого пользователя только что) С этого и надо было начинать.

Только узнал. Планировалась работа с 1 пользователем.

избыточность хеш vs гуид?

Ну вообще в РАУЗ доп. справочники есть.

Что то напоминает биржевое ПО для брокеров, или биллинг, или торговля... Пример 15 полей можно? Данные просто грузятся или зависят от документа? Что за отчеты? Может агрегаты настроить? Или добавить регистры накопления? Счета выставляются сразу по данным или раз в период?  Данные корректируются после загрузки ли только на чтение потом?   Решение лежит не в базе а в политике работы с данными: Сразу возникают вопросы, наличие всех 100 000 строк обязательно? Может достаточно будет одной строки с начало, окончанием, объемом, объемом нарастающим и ценой и т.д. Наборы из 15 полей может можно сгруппировать? Например, повторяются контрагент, договор и тип цены, храним тогда три поля в одном месте, а ссылку используем для загрузки? Трудно выдать решение сразу...

Может это и анализ в торговле, тогда непонятна цель такого анализа, а на просьбу сделать всё, можно делать много и долго... Если биллинг, то грузим частями и сразу считаем нужные итоги. По данным итогов выставляем счета. Распечатку исходных данных берем из базы. но это долго и дорого. Если данные все засунуть в реквизиты, то грузить может будет и ещё быстрее. Необходимость документа как только коммита мне не понятна. Если распровести документ, то 100 тысяч записей снова грузятся в регистр?

В принципе нужен клиент-сервер, а там уже посмотреть, как ты формируешь запросы в отчетах.

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

В принципе мы никак не дождемся структуры регистра.

Данные не зависят от документа. Теоретически, я могу счета формировать и по общим итогам. (Счета выставляются в любое время)   Тогда остается только то, что все эти строки нужны для детальных отчетов и сгруппировать ничего нельзя.. Данные корректируются очеень редко. Бывает, что нужно изменить какую-нибудь строку или параметр за определенный период, поэтому нужны документы с табличной частью. а в не структура? Или я не правильно понимаю, что конкретно вы подразумеваете под "структура регистра". Типы: строка,число, дата + справочникссылка

Измерение2 - серия. и.т.д.

Ага, присоединяюсь... ТС публикуй ТЗ, счас тебе насоветуем. По мне так важна цель, что делаем!!! Что решаем ))) Ведь все придумано до нас!

Сейчас вот так. Измерение1 - НомерТелефона - справочник Измерение2 - ВремяЗвонка Решаем, в каком режиме эффективней работать с большим количеством данных и как уменьшить объем базы. Конфигурация уже есть и с ней работают. Все устраивает, кроме этих моментов.

Наконец-то. Спасибо, поржал. Переделывай. Нужен оборотный регистр. Время и дата будут писаться в предопределенное поле "Период". Нормализуй данные - введи в регистр контрагента и договор. Номер телефона перетащи в реквизиты договора. Создай справочник звонков, в который ссыпай описание, исходящий и входящий номера, роуминговую сеть. Ресурсы числовые - можно не трогать. Врубай на регистр агрегаты, рассчитывай оптимальную сеть. Тупить база перестанет однозначно. P.S. Так и думал, что на РС пытаются регистр накопления эмулировать...

И добавить, то почти нечего. Ну разве малость. Может писать не измерения (1,4,5,9,10,12) А какой-нибудь тариф с договором.

Без табличной части можно обойтись и редактировать набор записей регистр в форме документа.

Почему именно оборотный? Мне нужно хранить детальные записи, чтобы получить, например, детализацию по номеру за пару дней или месяцев. А как это сделать, если я введу Контрагента и договор (А в договоре будет 20 номеров)? + все параметры нужны при распечатки детализации Про справочник не совсем понял. Предлагаете создавать справочник, куда заносить записи о каждом звонке(соединение, смс и т.д) ? (Каждая строка уникальна)? Уже разобрался, что-то протупил сначала.

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

не очкуй, добавляй ещё 32 гига памяти и переводи 1с в клиент-сервер на оракл.

Начиная с 8.2.14 можно использовать внешние источники данных. Если таблицы будут сильно пухнуть, тогда master-данные можно вынести во внешнюю СУБД.

Не надо постить откровенную лажу, я искренне сомневаюсь, что вы умеете готовить 11 оракл.

Верю ,Prilepsky научится. Тем более под боком пухленький клиент, на котором можна поэкспериментировать. Запомните, дети, биллинг это много денег.

Но и труда немало.

Где подробней можно почитать как использовать эти внешние источники?

В дополнении к документации. Кстати, можно использовать, например, Microsoft master data service for SQL Server

Т.е. идея выносить точку вводу информации во вне, т.е. создание своего рода БД нормативно-справочной информации (НСИ).

Уточню не БД НСИ, а исходные данные (листинги звонков) отдельно и базу счетов (биллинг) отдельно. Отделяем мух от котлет.

Кодд в гробу перевернулся%)

Ты для брокеров на бирже 1С не видел )))))))

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

а че там тоже заставляют "ОписаниеЗвонка" в измерения засовывать?

Нет там что купил, сколько, по какой цене, короче вся биржевая торговля ссыпается в один документ по клиенту, а потом на это уже идут расценки услуг брокера выставление счетов. Жуть в реальном времени почти... И объем неслабый