Имя: Пароль:
1C
1С v8
Хранение большого объема данных
,
0 r_p
 
05.11.13
10:38
1. В регистре сведений 71% (5)
2. В таблице БД SQL, выборка через внешние источники 29% (2)
3. В справочнике 0% (0)
4. Ты дурак? 1С для такого не предназначена 0% (0)
5. Свой умный ответ 0% (0)
Всего мнений: 7

Аллоха. Тема жуткий баян, но все же интересно узнать ваше мнение. Надо хранить, а впоследствии выводить отчет по неким данным. Данных много. Около 5-6 млн. строк. Индексировать надо по 2 полям. Одно число, другое перечисление, остальные реквизиты строки ограниченной длины. Где лучше в 1С хранить такой массив информации?
1 Ненавижу 1С
 
гуру
05.11.13
10:44
если других требований нет, то...

В регистре сведений
2 shuhard
 
05.11.13
10:45
(0) [Данных много. Около 5-6 млн. строк]
это не много

В регистре сведений
3 r_p
 
05.11.13
10:49
Выборка из регистра сведений долго отрабатывает... Но ладно. Это скорее вопрос к железу.
4 kiruha
 
05.11.13
10:57
(3)
1.Такой объем - индексы, ключи обновление и вставка - надо контролировать в "ручном " режиме. Регистр сведений этим требованиям не отвечает.
2.Проблемы с такой табличкой могут вывести все 1С в аут .
3.Собственно администрирование такой таблички средствами SQL никакой проблемы не составляет

В таблице БД SQL, выборка через внешние источники
5 kiruha
 
05.11.13
11:04
+Регистр сведений не умеет делать Update, не умеет "нормальный" Insert для большого количества записей  , не умеет строить произвольные индексы
6 Kreont
 
05.11.13
11:08
только не в файловой базе :)

норм.1с-ка справится, правду говорят что это не много.

с другой БД "минусов" больше будет.

В регистре сведений
7 r_p
 
05.11.13
11:13
Я все больше склоняюсь к 3 варианту. В перспективе данных будет до 30-40 млн. записей.
+Эти данные не нужны оперативно, а требуются для 2-3 отчетов.
8 kiruha
 
05.11.13
11:16
(7)
А зачем в одну таблицу ?
Представляешь сколько будет перестройка индекса ?

Наверняка это какая то "выгрузка" из нормальной базы
9 Kreont
 
05.11.13
11:18
вообщето любой SQL-ной базе пофиг на объем, упирается только в размер винта.(1С в т.ч.).

ну и тебе ж не надо будет выводить все данные, а строить по ним отчеты, если то все будет в 1С намного проще сами отчеты будет рисовать в СКД.
10 MadHead
 
05.11.13
11:19
(7) 30-40 для регистра сведений будет многовато. Действительно лучше вручную индексы строить к такой таблице. Еще немного и можно о hadoop задуматься )

В таблице БД SQL, выборка через внешние источники
11 kiruha
 
05.11.13
11:19
(9)Не пофиг
Но есть специальные механизмы
>>Секционированные таблицы и индексы
http://msdn.microsoft.com/ru-ru/library/ms190787.aspx
12 MadHead
 
05.11.13
11:19
+ внешнией источники данных сильно упростят жизнь
13 MadHead
 
05.11.13
11:21
(11) а если ему все данные надо выбирать или из разных секций, то может же и навредить секционирование?
14 Лефмихалыч
 
05.11.13
11:24
тупая ветка

В регистре сведений
15 Kreont
 
05.11.13
11:26
(0) а вообщето, создай в 1С РС, заполни циклом 30 млн., сделай выборку СКД по любому условию.
а теперь попробуй сделать все то же в другой базе).

индексированим вместо 1С-ки занимается сам сервак БД, при номальном настроенном кроне (автовакуум для постгреса), ну или на каждодневный запуск, без разници будет что держать такие данные в другой таблице что на РС.

а и да 30-40 млн. это также вовсе не много.
16 kiruha
 
05.11.13
11:27
(13)
Ну как автор организует секции , структуру и индексы -  так и будет работать.

Но вообще механизм секционирования как раз для больших таблиц создан. Вступление от хабра
http://habrahabr.ru/post/74984/
17 kiruha
 
05.11.13
11:28
(15)
Можно поинтересоваться если нужно будет обновить 500 000 записей по одному столбцу - что делать ?
Сколько ждать ?
18 MadHead
 
05.11.13
11:28
(15) 1с плохо занимается индексацией. Строит только составные индексы. Другое дело, что автору может хватить кластерного индекса
19 MadHead
 
05.11.13
11:30
(17) Если удастся выкрутиться наборами записей то ждать не так уж и долго прийдется
20 kiruha
 
05.11.13
11:35
(19)
Ну почему то 1С уходит в аут на достаточно долго при записи больших наборов. Что она там столько делает я не знаю
Тем полно, способов лечения я лично не нашел
21 MadHead
 
05.11.13
11:43
От железа конечно зависит. Но у нас в базе набор записей в 500к строк и 6 колонок записывается за пару минут. Средствами скуля тоже самое происходит за 5-10 секунд.
22 1dvd
 
05.11.13
11:45
Не нравится 1С - пиши свою с чатланками и плюком.

В регистре сведений
23 kiruha
 
05.11.13
11:48
(21)
Разница в 10 раз.
Но больше волнует запись в регистры Бухгалтерия/накопления. Там разница раз в 100. Рекомендации какие то сомнительные - отключить итоги (и видимо потом ждать 2 часа пересчета итогов), установить монополный режим (а пользователи ?), обновлять в фоне .
24 zladenuw
 
05.11.13
11:51
(23) а разве в 8.3 не быстрее ? маня же делал замеры что 8.3 в 10 раз быстрее 8.2 или туфта ?
25 Zixxx
 
05.11.13
11:53
(0) 5-6 млн. это очень мало, да и вообще какая разница сколько записей 5 млн. или 500 млн. ты же в индекс попадаешь, а не все данные получаешь.
26 kiruha
 
05.11.13
11:54
(24)
Спасибо поищу - даже где то видел, что там запись в регистр оптимизировали
27 AaNnDdRrEeYy
 
05.11.13
11:56
5-6 млн это совсем копейки, большой разницы все равно не увидишь. главное не в чем хранить а сколько потом показывать человекам. вот вывести все эти данные в таб док или СКД вот это да проблема. если будешь выводить небольшими порциями по паре тысяч строк, то не парься по таким пустякам.
вопрос справочник или регистр совершенно некорректен, - попробуй сделать ссылку на запись регистра.... как собираешься использовать так и делай.
28 r_p
 
05.11.13
11:57
В итоге сделаю и в регистре записи и в БД MSSQL. Протестирую и решу.
29 Zixxx
 
05.11.13
13:14
(28) А регистр он что вне БД MSSQL будет что-ли создан платформой?
30 mzelensky
 
05.11.13
13:25
(0) объем реально не большой. 5-6 милионов запуливаешь в РС и все работает норм.