Доброго времени суток!
Сейчас встал забавный вопрос - имеется большой объем данных, который необходимо перенести в 1С-кую базу. Информация состоит из 30 миллионов записей (строк). Каждая запись содержит 100 полей (колонок).

Внимание вопрос - куда и как все это записать?!

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

Но на сколько я понимаю 1С-ка не расчитана на такие объемы однйо таблицы...

Рассчитана

регистр сведений

ну вообще может лучше просто в SQL табличке, все зависит от задачи

мы про файловую или скуль?

1c должна потянуть,
(но накрайняк всегда можно создать скульную базу,если это просто таблица - и из базы 1с запросами получать данные)

(3) +1)

(2) в регистр не хотелось по причине того, что в справочнике это более наглядно бы выглядело:

" В табличной части будут храниться реквизиты, их значения и доп. информация по этой записи."

(4) в идеале файловую. Если не потянет, то прейдется скульную

(0) отдельнную базу на 1С+SQL,и туды конекшен по СОМ.........

"на сколько я понимаю 1С-ка не расчитана на такие объемы однйо таблицы"

какой бред

(5) это усложняет процесс формирования отчетов в последующем :(

но на файловой - не потянет

(11) Внешние источники запретили?

(11) не капли) тут главное структуру продумать

(10) ну почему же бред. На этом же самом форуме были сообщения, что 1С-ка начинает тупить, если в одном справочнике хранить более 100 тысяч элементов. А тут 30 миллионов + он будет расширяться

(15) на форуме может быть всё, что угодно...

(15) от структуры данных зависит, еще на 8.1 справочник номенклатуры в одной из баз был под 400к элементов - всё ок было)

(15) лол. наверное, почти у всех справочник Контрагенты содержит куда больше 1к элементов

(7) То как выглядит - настраиваемо.
Зависит от дальнейшего использования. Например - необходимость отбора по отдельному реквизиту.
В общем, имхо, посмотрите - где и как будет использоваться информация, какие нужны будут индексы, какие мозможно блокировки и отсюда выбирайте

+(18) про номенклатуру молчу

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

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

Справочник - если нужны уникальные GUID для ссылки на запись таблицы. Регистр сведений - если есть очевидный уникальный набор небольшого количества реквизитов, чтобы поддерживать небольшой размер записи кластеризованного индекса.
В иных случаях - справочник.
Файловая база ограничена в 2 Гб на 1 таблицу. 30 млн записей по 100 колонок уже получается 3 млрд ячеек. Так что - только SQL.
Для хранения 1С такой объем потянет ВЛЕГКУЮ. Проблемы будут, если нужны будут составные индексы. Смысла выносить данные вне базы 1С - вообще никакого смысла
ПЫСЫ: Длину кода и длину наименования справочника выставить равные 0, без владельцев и иехрархии. Так останется единственный кластеризованный индекс по GUID.

(17) Номенклатура более 100к элементов создает только одну проблему - документ изменения цен не записывается. В документе возможно не более 99 999 строк. А при наличии, скажем, 5 типов цен в нашей базе с порядка 700 000 номенклатурных записей, в перестановке цен получалось 3,5 млн строк. Приходится  переразбивать документы :(

(22) спасибо за инфу!

(23) Один из вариантов - отказаться от хранения данных и делать псевдо табличную часть на регистре сведений

реквизиты конечно лучше реквизитами делать а не в тч

я такого рода данные храню во внешних файлах. Разбил по папкам и - вуаля.

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

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

сейчас у меня есть задача фрилансеру по интеграции 1с и файер берд. Как сделаю, поделюсь, можете юзать.

(29) а че там интеграировать? FB понимает адо.

(23) Переписывать код типовой УТ, зачем? Гораздо проще заполнялку переделать.
(27) Транзакции? Не, не слышал...
(28) Какой такой проверка целостности? СправочникОбъект.Удалить - и никакой целостности :D
Для хранения лога использование справочник - это конечно жесть. Никакая БД для этого не подходит, только текстовый файлик.
(29) Вроде внешние источники данных чудесно понимают FB.

(30) хз, счас уточню...

Отлично, 30+ и ни слова ни вопроса, что за данные и что с ними будут делать.

(28) (31) это не лог. Это именно справочные данные.

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

(26) 101 реквизит?!

(35) И всё булево )

(34) вот, изучай.

http://infostart.ru/public/152847/

в файловой у тебя будет попа, если надумаешь.
один chkdbfl, а он запускается раз в две недели, будет висеть мертвым грузом.

К тому же есть ограничение на 4 Гб на одну таблицу.

У меня в PIM в базе 500 000 сообщений (отправтель + получатель + текст) и то я вешаюсь. При первом запуске 1с минут 10 раскочегаривается, осваивая в памяти базу на 5 Гб, только потом начинает запросы пускать нормально... Потому и думаю о фиреберде.

Можно хранить во внешней MongoDB и прописать алгоритмы записи/чтения

(0) Внешняя база на SQL, запросы по ADO.

Что за справочник такой, на 30 миллионов записей? Больше похоже на биллинг какой то

(40) ксати да, как вариант

(40) токо у чела нет SQL-сервера, раз он хочет юзать файловую

пусть ковыряет фаерберд, она портабельная

Гений, как всегда, бред Питит.
(22) - все годно и все по теме.

(43) Странный человек. Ну пускай ФБ, пускай MySQL...разница в строке подключения.

(43) Откуда инфа?

Чо за данные храняться?

со скулем надо париться со структурой, таблицами и запросами, а с монгой - нет. Подчиненные объекты прямо с родительским получаются одним запросом

(49) Одна таблица!:):)

Я лучше Скуль разверну.
Это не проблема

>>> В идеале это должен быть справочник с табличной частью. Каждый элемент справочника будет представлять собой одну запись. В табличной части будут храниться реквизиты, их значения и доп. информация по этой записи.

Если есть табличная часть, то уже одна подчиненная таблица

(51) Что за тип данных будет храниться?

(53) Ждите 1С: Социальная сеть

(54) ВКонфигураторе!

(53) Параметр (реквизит) - справочник или характеристика
Значение ппараметра - пока строка. Позже, возможно, будет составной тип (строка, справочник, перечисление).

Т.е. в принципе классическая схема - характеристика и ее значения.

(54) могу еще испугать. 30 миллионов это информация ток за текущий год. А еще есть 2009,2010 и 2011 года :)

Итого, за 4 года получаем примерно 100 миллионов записей.

я за отдельностоящую базочку и ADO
совершенно не обязательно MSSQL, что под руку попадётся
MySQL

>>> примерно 100 миллионов записей.

Тем более нужна внешняя база.

(51) проблема в бабках, MS SQL денег стоит.

(60) на бесплатном можно до 10ГБ базу создавать

(0) Ты справочник СЕКУНД в году заводишь что ли? Это 31 536 000 записей! Генерация 30 000 000 записей в год при режиме 7х24 - это практически 1 запись в секунду. Если не наблюдается равномерности заливки данных, а имеют место пиковые нагрузки (например, в 19:00 люди приехали домой и зашли В контакт), весьма вероятны проблемы с производительностью потока записи.
Опиши, что и с какой целью ты собираешься заливать в 1С.
ПЫСЫ: Концепцию динамической табчасти забудь, как страшный сон. Это непроворотливый монстр.

(62) а как тогда предлагаешь писать реквизиты, если не в табчасть? Создавать все эти реквизиты ???

(1) Ты бы лучше написал еще что из себя представляют эти данные. Может быть эту твою таблицу можно нормализовать

В смысле (0)

(63) Опиши предметную область и суть объектов, которые ты собираешься поместить в таблицу

(64) там нечего нормализовать. Уже и так все структурированно и ужато до предела.

(66) да что не понятно.
фейсбук наняло программист 1С, для перехода на прогрессивную платформу.

(68) 1 млрд лицензий 1С!!!!!!! Возьмите меня хотя бы полы мыть в компанию, которая будет делать фейсбук на 1С.

(69) Это будет 77, неограниченая

(0) Учти, что в табличной части не может быть больше 99999(!) строк! Это ограничение платформы, которое везде замалчивается.

по идее, можно если не заморачиватся сделать 1совские базы с 1м регистром, для хранения и простейшего синтаксиса, цеплятся к ним через com или прямыми запросами, но при этом всегда можно будет слить базы или забэкапить не загружая основную базу.

по сути реализация кладра и бик для 7.7 мне кажется оптимальной. Если конечно не надо insert делать, для инсерта делаем регламентное задание/сеанс/робота.

(71) количество строк в ТЧ будет небольшое. 100-200 строчек.

(73) Тогда приступай смело, 1С справится :)

(0) Решали подобную задачку для ценных бумаг , хранили все в регистре сведений
off: Чо за мот? Драга?

(71) Чойта не может.

(76) А попробуй)))

(77) Может нумеровать не может? В 7ке тоже было, но органичение на нумератор, а не на количество строк. А это какбэ разные вещи.

http://imageshost.ru/photo/208654/id2649021.html

Вот, что получается при добавлении в табличную часть большого количества строк.

хорошо бы 1с для этого сделала механизм

(0) Внешние источники данных?

(82) Еще вариант: можно на 1С накатать такую маленькую конфу и работать с ней через ком. И не парит основную.

ИБ 1С файловая не работает если хотя-бы одна из её таблиц превысила 4 ГБ. Можно 1С в MS SQL Server и лучше пусть MS SQL поновее будет (от 2005 и выше).

Хранить данные лучше в справочнике, так как при записи в регистр сведений проводится контроль уникальности в разрезе измерений и периода. К чему это приведет при 30 млн записей понятно?

(0) Создай вьюху на скл