Доброго времени суток господа :)

Заинтересовал меня недавно вариант разделения БД на транзакционную и аналитическую части. Причем если транзакционную можно оставить так как есть на 7.7 то аналитическую можно реализовать только под 8х (потому как записи можно отвязать от регистраторов и запросный блок + отчетность дают свои преимущества).

Вобщем в связи с этим возник вопрос. Можно ли использовать вариант отличный от конвертационного в частности организовать обмен только изменившимися данными (т.е. по аналогии с планами обмена но из 7 в 8).

Может кто уже работал или исследовал проблему ?

Господин ПЖ, эээ как бы объяснить... наврное неверно сказал что именно "отвязать полностью" - оставить объект-регистратор то прийдётся но ведь уже не обязательно тянуть всю его таблично-шапочную часть (а их скажем тысяч по 40 и больше бывает строк этих в одном документе) как и все реквизиты справочников - оставить только идентификаторы для основой базы да и все


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

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

да даже если и справочники сделать "урезаными" всё равно помочь должно - вопрос в отслеживании изменившихся объектов в транзакционной... не тягать же весь период если что-то поменялось

авторИли у вас консолидация?

:) нет... таких перцеф не так уж и много

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

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

автори переписывайте отчеты на прямые запросы 1С++

этот вариант рассматривался но есть на данный момент у меня 2 причины

- не могу под 2003 64х поставить ++ :)
- в SQL уменя реальный проблемы т.к. весь опыт ограничен годом небольшого опыта пятилетней давности

Злой Бобр, есть и такой варинат (используется для инвентаризаций выездных и в другой маленькой на 5 гиг базе) но он файловый может потому и скорость не выше

кстати а сгенерить распределёнку такой немаленькой базы (21 гиг) я смогу (делается на 2003 64 2,4 проц и 3гб оперативка) ? а то когда пробовал загрузить в новую её же выгрузку то висел процесс 4 дня после чего я его благополучно снял


авторЕсли отчеты делаются в течение 4-10 часов (а при этом сами данные ещё могут часто меняться), значит не всё нормально с самой организацией базы данных (либо не нужна оперативность самих отчетов).

не нормально с организацей но жаловаться я не буду (скажем на цепляние по одному документу на регистер с совокупным 5-10 кратным дублированием данных плюс по остаточным регистрам скажем не проблема вбить почти десяток измерений из которых используется половина) просто отчетность хранить надо до 5 лет (ювелирка) и анализ для производства идет с выборкой данных за 3 года (динамика сезонность и т.д.)

авторМожет сохранять уже готовые отчеты в виде документов, чтобы потом просто открывать их, а не перестраивать.

ну понятие "закрытого периода" тут слава богу существует (хоть и квартально) но что-то мне кажется не сильно так вариант

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

может и так... хуже базе уже не будет насколько я понял

Masygreenсоответственно нафига их строить каждый раз непонятно

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

плюс ежемесячно и ежеквартально минфин минфиг минещёчего-то... т.к. производство уж очень стрёмное для государства

Masygreenу вас прямая дорога построить OLAP

это нереляционные СУБД ? ну не думаю что переезд туды будет дешевле оптимизации и таки подключения "прямых" запросов... хотя может и ошибаюсь... а есть решения для связки с 1С чтоб минмум затрат на обслуживание сторонними кодерами самих этих СУБД ?

попробовал сгенерить распределёнку "только получатель" - после битв за "большой размер выгрузки" (стандартом больше 1,15 гиг не зипует и соответсвенно при загрузке сиго чуда ругается) в котором помогла вещица для выгрузки больших баз]http://infostart.ru/projects/1512/ и оказалось что сам файл данных весит больше 4 гБ ( это из той БД которая урезана до 11 гб)... ну то мелочи

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

даже вот и не знаю считать ли это временной победой советских инженеров :)

авторэто не тот прирост, ради которого стоило все затевать.

это точно :)

по поводу остального я так понял предлагается вариант "плавного переезда" :) т.к. я не понимаю зачем перекидывать в восьмерку весь документ (разве что если организовывать конвертацией и и тяжело из 7ки будет получить и обработать данные запроса для формирования движений уже по 8чным регистрам с привязкой к объектам у которых "дата+номер"... а не просто перетягивать объекты) для аналитбазы... там есть доки с 40 тыс. и более строк... зачем их тянуть в восьмерку полностью... разве что для переезда

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

Алексей2003, вот в том то и дело - претягивать же можно только данные которые нужны для отчетности и в том виде который нужен без избыточности для контролей остатков и т.д. которые необходимы в транзакционной части для обеспечения корректности ввода данных

зачем дублировать ТЧ + регистер ? разве не достаточно будет оставить что-нить одно ? (переезжать полностью пока не планируется... во всяком случае не с такой структурой учета как сейчас в 7ке)

а насчет того в чем хранить (ТЧ или регистры) это вопрос - где будет лучше крутить отчетность - на документах или регистрах ? в 8ке то особых вопросов в получении итогов по разным регистрам и таблицам объектов то нет (не так как в 7 ке - чтоб получить что-то работающее одним запросом по нескольким регистрам с разношёрстной структурой нужно очень сильно извернутся с потерями как правило и в скорости и в удобности для юзера)

вот как быстрее будет шуршать запрос... по документам или регистрам ? (при условии что структуры подобны)

авторчто хотите хранить в регистре, хранить в табличной части документа. изменение этих данных увеличивается на 60-80%.

извините вы уже ответили на мой вопрос :) я не прочитал... спасибо за совет... получается по документам таки быстрее ?

Алексей2003, тогда от дублирования никак не уйти получается ? единственный плюс только в том что уже в доках ТЧ и движения их могу формировать отличные от 7чных и оптимизированные под конкретные отчеты так получается