Собственно сабж

какой лучше выбрать объект для хранения больших объемов более 500 тыс записей?

ежемесячно получаю по 600 000 записей из mysql
со следующими полями
лицевой счет
принадлежность
аскуэ
показания обхода
дата показ обхода
предыдущие показания
следующие показания
достоверность пред
достоверность след
флаг
датааскуэ

их надо где то хранить в 1 с ...ну и соответственно обрабатывать и строить отчеты, делать выгрузку в dbf формат

система 1 с 8.3 и субд ms sql

склоняюсь к регистру сведений периодическому независимый

кто что скажет порекомендует?

записывай в амбарную книгу

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

Рекомендую попробовать на копии

Минусы независимого РС - записи из него могут взять и одномоментно пропасть по неосторожно дрогнувшей руке

500 тыс это больные объемы??? да вы что..

у меня вот 1.5 млн записей в справочнике легко лежит на 7ке счас вот в постгри запихнул кое-что на 2 млн записей..

600 тыс падают ежемесячно
естественно они накапливаться будут....
за 10 месяцев 6 млн

(5) ну у него 600000 в месяц, только за год набежит больше 7 млн

(7) Это тоже не сильно много. Вот когда у него будет 600 тысяч в день...

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

(6) Да ладно, не много это. У меня в одной конфе около 2 млн документов в месяц падает, и ничего, работает...

или лучше разбить один регистр на несколько по рэсам?

Если какие то ограничения на измерения?

(11) Длина ключа (комбинация всех измернений) не больше ~1000 символов

Считай, что одно ссылочное измерение (ГУИД) занимает 36 символов, отсюда не больше ~28 ссылочных измерений

(если гоню, то знающие люди меня, надеюсь, поправят)

(11) Стандартно. Уникальность измерений (включая служебные).

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

(14) Гонишь. 16 байт.

Ключом может быть не только комбинация измерений так?

Что порекомендуете для установки данных регистра измерения?

я имею ввиду измерения , ресурсы и реквизиты

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

(16)

SQL Server 2008 R2 Другие версии
При проектировании индекса, содержащего множество ключевых столбцов или столбцов большого размера, следует вычислить размер ключа индекса, чтобы удостовериться, что он не превысит максимальный. В SQL Server сохраняется предел в 900 байт на максимальный общий размер всех ключевых столбцов индекса. При этом исключаются неключевые столбцы, входящие в определение некластеризованных индексов.

(18) Что будет измерениями нужно исходить из предполагаемых запросов к таблице, учитывая что измерения войдут в составной кластерный индекс
А с учетом того, то у регистра сведений индекс всегда избыточно составной, и в него всегда входят измерения, даже если индексируешь по ресурсу, то можно рассмотреть регистр накопления + регистратор типа "Корректировка регистров", как в типовых конфигурациях.
http://its.1c.ru/db/pubapplied#content:352:hdoc
http://its.1c.ru/db/pubapplied#content:357:hdoc

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

(16) А, ну тогда максимум 56 измерений (896 байт) может быть в независимом регистре сведений, так?

видел регистр накопления, в котором было 45 лямов записей...

(6) Если это все append-only, то лучше положить во внешнюю базу. Или оставить в той же Mysql. Отчеты строить по внешнему источнику данных.

оставить во внешней базе, лазить по необходимости.

Отчеты быстро строятся по внешнему источнику??

для  таблиц с 500 тыс и 12 млн

а могу я постороить отчет по http сервису(вытвскивать оттуда данные) ?

смысл в чем у меня 2 источника данных

mysql база
и http-сервис (но мне опять же надо сделать post запрос и заведомо знать какие значения параметров отправить (эти значения я получаю из mysql) )

(25) Попробуй и рссскажи нам.

(26) Данные кладешь в ТЗ, ТЗ суешь в СКД.

ТС скажи в каком МРСК такое реализуют, кто отказался от святого IS-U.

(0) объект никак не выбирается исходя из количества строк.

(18) такие вещи тоже не рекомендуются, а определяются исходя из условий получения и хранения данных.

может там и одного измерения хватит - лицевой счет, с периодичностью месяц.

(25) вообще не быстро будет

(31) периодичность месяц не покатит, съёмов показаний может быть несколько

вот измерений да, л/с должно хватать

может кто объяснить на что влияют измерения,
я так понимаю для быстрого отбора именно по измерениям? так?
что записывать в ресурсы и что в реквизиты

ведь регистр сведений мне понадобиться для построения отчетов а также для выгрузки dbf

Измерения влияют на количество "разрезов" записей - две записи с одинаковыми измерениями в регистр не запишешь

по сути тогда лицевой счет в измерения так как он уникальный + дата

а в ресурсы и реквизиты что?
чем они отличаются?

можно вообще внешнюю таблицу заюзать

РС с одним измерением УИД - это и есть справочник

(38) через внешние источники?поподробнее

мне необходимо что бы по полученным данным можно было построить запросы
например по срезу последних сформировать все лицевые счета с одного рэса

алгоритм следующий

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

затем запросом получаю срез последних все лицев и дополн инфу по им ,отправляю пост http запросом получаю ответ - его в тз, и соединяю с Регистром Сведений по лицевому счету.

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

Для таких количеств рекомендую Oracle и на PL/SQL написанные вибюхи с хранимками по триггерам.

Которые отдельные готовые сводные таблички-отчетики в том же оракле.
А из 1С к этим готовым сводным табличкам как внешним источникам данных подключаться и выводить...

(43) *вьюхи = views

(43) можно вызвать хранимку на mysql через 1 с через ado?

(45) смотря какой mysql, но да

(46) мне все равно надо тянуть данные на клиента
надо выгружать dbf
и еще взаимодействовать с http сервисом

(43) тем более удаленным сервером я не занимаюсь
для этого есть другой человек

(47) (48) Суть если нужно быстро то с такими объемами это не к 1С.
В 1С все что выше сотен тысяч это долго. медленно и мучительно.
Но если подождать несколько часов или суток устраивает то можете делать.

Хотя смысла не вижу, там 100% данные простые линейные с простыми привязками по id.
Все можно на хранимках сделать и по команде из 1С (с параметрами) будет готовая для записи в DBF выдаваться табличка.

(49)а как взаимодействовать с веб-сервисом?

2(0) Внешний Источник данных. к тому же МайСКЛ. ему надо - пусть он и хранит. А 1С - интерфейс.

(0) Хранить в сторонней бд записи, из 1С только дергать нужное (51) короче

(39) Добавь туда пометку удаления, версию, имя и флаг предопределенных данных. Это по минимуму.

(49) В кривых рученьках то конечно.

(54) это еще вопрос у кого они кривее

с веб-сервиса миллионы записей тянуть?
И кто-то тут будет говорить о скорости?
Или через адо те же миллионы?
Вы, ребята, с дубу рухнули?

(54) + дохлое железо

(56) Ну у них в тестах то все ок будет, на паре тыщ записей ))

(57) Дохлых желез не бывает. Уже лет 10 как.

(59) бывает мало денег и/или жаба давит

(60) В современном ИТ дохлое железо ты найдешь в каких-нибудь ипинях, и то вряд ли.

(59) (61) А что будет если на самом навороченном железе несколько дятлов одновременно запустят подобную (0) заливку данных в одну базу?

(62)+ типа за разные месяца...

(62) Данные будут записываться. В чем смысл вопроса то?

(63) видимо ничего страшного, если в РС месяц будет измерением
в РС вроде по умолчанию блокировка по измерениям при записи

(64) Советую потестировать.
Особенно в случае замены записей по составным полям поиска (без индексов) и еще "разработчик" не в курсе про транзакции.

(65) Ну да месяц измерением когда ТС походу не в курсе что записи могут придти в текущем месяце за любой предыдущий...

(66) Я в курсе про замену. И чем мне кажется, тут пасует любая СУБД, если предварительно запись надо найти и обновить (или удалить и записать новую с тему же ключами, как это почему то делает 1С).

Либо либо предварительно очищать регистр набором записей с отбором по периоду (месяц) и затем записывать не замещая (РС.ОбменДанными.Загрузка=Истина; РС.Записать(Ложь)), либо медленно через РС.Записать(Истина)

Ну можно еще один в один данные из MySQL (чужой) переносить в MSSQL базу (свою).
Затем написать на T-SQL нужный код.
И юзать написанные хранимки/вьюхи через внешние данные из 1С. Для отчетиков и вывода в DBF.

Тащит все данные вместо только сводных в базу 1С не вижу смысла.

написал запрос к mysql
к таблицам к kartab_askue и kartkvdg_askue

select t2.yearmon,
t2.lic_sch,
t2.data_new,
kartab_askue.lic_sch,
kartab_askue.data_kon,
kartab_askue.date_kon,
kartab_askue.base
from
kartab_askue Left JOIN (select t1.yearmon,
t1.lic_sch,
kartkvgd_askue.data_new
from
(select MAX(kartkvgd_askue.yearmon) yearmon,
kartkvgd_askue.lic_sch
from
kartkvgd_askue
where kartkvgd_askue.del=0
GROUP BY kartkvgd_askue.lic_sch) t1 inner join kartkvgd_askue
on t1.lic_sch=kartkvgd_askue.lic_sch and t1.yearmon=kartkvgd_askue.yearmon) t2
on kartab_askue.lic_sch=t2.lic_sch
where kartab_askue.del=0


могу ли я его разбить на подзапросы на вьюхи
и потом вызывать главную вьюху через ado

(69) https://dev.mysql.com/doc/refman/5.7/en/create-view.html

(70)+ https://dev.mysql.com/doc/refman/5.7/en/views.html

(0) По идее в 1С объект метаданных выбирается исходя не из объемов, а из его прикладного смысла. У вас, видимо, регистр сведений. Что будет его измерениями, что ресурсами, что реквизитами тоже.

Что касается объемов - нужно пробовать, мне кажется вполне потянет.

в чем преимущества использования вьюх от простого запроса?

бЫСТРОДЕЙСТВИЕ?

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

(74) вьюха тот же запрос. но скажем так статичный и сохраненный. бывают индексированные вьюхи, они физически хранятся.

(74) будет при обращении к ней.

материал вью.

(69) зачем вообще здесь вьюхи?

сама вьюха

elect t2.yearmon,
t2.lic_sch,
t2.data_new,
kartab_askue.lic_sch,
kartab_askue.data_kon,
kartab_askue.date_kon,
kartab_askue.base
from
kartab_askue Left JOIN (select t1.yearmon,
t1.lic_sch,
kartkvgd_askue.data_new
from
(select MAX(kartkvgd_askue.yearmon) yearmon,
kartkvgd_askue.lic_sch
from
kartkvgd_askue
where kartkvgd_askue.del=0
GROUP BY kartkvgd_askue.lic_sch) t1 inner join kartkvgd_askue
on t1.lic_sch=kartkvgd_askue.lic_sch and t1.yearmon=kartkvgd_askue.yearmon) t2
on kartab_askue.lic_sch=t2.lic_sch
where kartab_askue.del=0

Вьюхи наверное из Ораклом приползли, где если уж строится план запроса, так он строится капитально.