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

если других требований нет, то...

(0) [Данных много. Около 5-6 млн. строк]
это не много

Выборка из регистра сведений долго отрабатывает... Но ладно. Это скорее вопрос к железу.

(3)
1.Такой объем - индексы, ключи обновление и вставка - надо контролировать в "ручном " режиме. Регистр сведений этим требованиям не отвечает.
2.Проблемы с такой табличкой могут вывести все 1С в аут .
3.Собственно администрирование такой таблички средствами SQL никакой проблемы не составляет

+Регистр сведений не умеет делать Update, не умеет "нормальный" Insert для большого количества записей  , не умеет строить произвольные индексы

только не в файловой базе :)

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

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

Я все больше склоняюсь к 3 варианту. В перспективе данных будет до 30-40 млн. записей.
+Эти данные не нужны оперативно, а требуются для 2-3 отчетов.

(7)
А зачем в одну таблицу ?
Представляешь сколько будет перестройка индекса ?

Наверняка это какая то "выгрузка" из нормальной базы

вообщето любой SQL-ной базе пофиг на объем, упирается только в размер винта.(1С в т.ч.).

ну и тебе ж не надо будет выводить все данные, а строить по ним отчеты, если то все будет в 1С намного проще сами отчеты будет рисовать в СКД.

(7) 30-40 для регистра сведений будет многовато. Действительно лучше вручную индексы строить к такой таблице. Еще немного и можно о hadoop задуматься )

(9)Не пофиг
Но есть специальные механизмы
>>Секционированные таблицы и индексы
http://msdn.microsoft.com/ru-ru/library/ms190787.aspx

+ внешнией источники данных сильно упростят жизнь

(11) а если ему все данные надо выбирать или из разных секций, то может же и навредить секционирование?

тупая ветка

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

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

а и да 30-40 млн. это также вовсе не много.

(13)
Ну как автор организует секции , структуру и индексы -  так и будет работать.

Но вообще механизм секционирования как раз для больших таблиц создан. Вступление от хабра
http://habrahabr.ru/post/74984/

(15)
Можно поинтересоваться если нужно будет обновить 500 000 записей по одному столбцу - что делать ?
Сколько ждать ?

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

(17) Если удастся выкрутиться наборами записей то ждать не так уж и долго прийдется

(19)
Ну почему то 1С уходит в аут на достаточно долго при записи больших наборов. Что она там столько делает я не знаю
Тем полно, способов лечения я лично не нашел

От железа конечно зависит. Но у нас в базе набор записей в 500к строк и 6 колонок записывается за пару минут. Средствами скуля тоже самое происходит за 5-10 секунд.

Не нравится 1С - пиши свою с чатланками и плюком.

(21)
Разница в 10 раз.
Но больше волнует запись в регистры Бухгалтерия/накопления. Там разница раз в 100. Рекомендации какие то сомнительные - отключить итоги (и видимо потом ждать 2 часа пересчета итогов), установить монополный режим (а пользователи ?), обновлять в фоне .

(23) а разве в 8.3 не быстрее ? маня же делал замеры что 8.3 в 10 раз быстрее 8.2 или туфта ?

(0) 5-6 млн. это очень мало, да и вообще какая разница сколько записей 5 млн. или 500 млн. ты же в индекс попадаешь, а не все данные получаешь.

(24)
Спасибо поищу - даже где то видел, что там запись в регистр оптимизировали

5-6 млн это совсем копейки, большой разницы все равно не увидишь. главное не в чем хранить а сколько потом показывать человекам. вот вывести все эти данные в таб док или СКД вот это да проблема. если будешь выводить небольшими порциями по паре тысяч строк, то не парься по таким пустякам.
вопрос справочник или регистр совершенно некорректен, - попробуй сделать ссылку на запись регистра.... как собираешься использовать так и делай.

В итоге сделаю и в регистре записи и в БД MSSQL. Протестирую и решу.

(28) А регистр он что вне БД MSSQL будет что-ли создан платформой?

(0) объем реально не большой. 5-6 милионов запуливаешь в РС и все работает норм.