Влияние количества общих реквизитов на производительность #266699

Общие реквизиты тормозят базу. Кто нибудб - реально это наблюдал? Добавить к документам общий реквизит или все таки обойтись локальными реквизитами?

Общие реквизиты тормозят базу. Кто нибудб - реально это наблюдал? Добавить к документам общий реквизит или все таки обойтись локальными реквизитами?

наблюдал.... думай

а вот ты подумай... ДОбавиь общий реквизит да с отбором - он будет в одной таблице... Без отбора - во всех таблицах шапок документов не общий - в тех шапках, куда добавил... Вот возьми бамажку и подсчитай, что места будет меньше занимать...

Зависит от цели которую преследуешь Попробуй запросец написать без общего реквизита и т.п. - будет ли удобно?

а причем место то?... проблема общих реквизитов в 7.7 - не занимаемое в базе место...

+1

+1

да типа при том, что 1с на 10Гб работает слегка медленней, чем на 2...

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

зависит от формата хранения данных

Ну расскажи... Просвети новичка... Неа.. не зависит...

, А что означает +1? Делаю выгрузку из ТиС в БуХ. В этом реквизите хочу прописывать внутренний идентификатор документа (внутренний по отношению к ТиС), потому что меняют номера, количества суммы и т.п. Сами, наверное, знаете как работают менеджеры. Локальный реквизит неудобен тем, что состав перегружаемых документов будет расширяться. Если кто подскажет свой способ, буду благодарен.

еще как зависит!!! спорим 10гб у меня будет работать быстрее чем 1-2 гб?

а реквизит то зачем?

видимо чтобы в бухии айдишник хранить в нем

Странный вопрос. А как еще идентифицоровать документ в "чужой" базе - заведен он или уже нет? Ведь по номеру или дате не вариант - могут поменять.

в точку

как было замечено в , общие реквизиты всех документов хранятся в одной физической таблице базы данных!!! И теперь, если идет массовый ввод документов, при записи каждого документа система будет ожидать монопольного захвата таблицы общих реквизитов - вследствие чего общая производительность системы упадет.. та же самая проблема есть и с хранением бухгалтерских данных.. +1 значит - "согласен с "..

да куча стандартных средств, зачем велосипед изобретать

рассказывай.

да это таже беда что у бухии,с проводками..

Ты открыл мне глаза! А если там не будет общего реквизита, ожидания захвата не будет?

Пробовал хранить в комментарии, но он используется.

+ а джорнал?

А можно ещё так... Завести _отдельную_ таблицу (ИДБазы, ИдДокТут, ИдДокТам)

П-п-п-п-поясни...

+25 не мне, а ...

да используй тот же МОД, проблем не будет. неужели для конторы жалко каких то 20 баков за готовое решение

всмысле таблица 1sjourn тоже же лочиццо

?

А где общие реквизиты с отбором хранятся? pb.ru

не слухай, а то он ща тебе и аксапту предложит )))

да, и еще как..постоянные траблы изза этого

компания ПиБи

никогда не был сторонником этой проги

я не говорил "ожидания захвата не будет"... я рассказал про проблему "общего реквизита".. заметь, в 8.0 нет общих реквизитов... что "джорнал"?.. он как тормозил, так и продолжит.. "общие реквизиты" добавят проблем к блокированию.. все таки, проще дождатся блокирования одной таблицы (журнала документов), чем  двух и более (журнала документов, таблицы общих реквизитов, таблицы констант и периодических реквизитов) итд..

Хороший вариант,спасибо. Но лишние движения.

А если ожидание блокировки не критично?

ух ты... мне б так :)))

А что, если докУмент записывается с изменением необщего реквизита, он не блокирует джорнал? чарминг новлти... А если блокирует, то какаянафигразница, для сколки реквизитов оно блокируется? Единственная проблема - это обновление индекса...

А тогда забей и делай общий с отбором.

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

Нет инфы под рукой - ид документа какого размера, что бы не делать неогранниченным?

зачем изобретать велосипед когда есть готовые решения... Гений 1С намбе ту?:))

смотря в каком формате будешь хранить: в 36-ричном 9

не думаю что готовое решение подойдет. Автосервис. Учет запчастей на складе, взаиморасчеты и оказание услуг в бухии.

это что - то из недокументированных возможностей?

так там план обмена настраиваемый, под любую конфу

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

ну в таблицах хранятся в 36-ричном формате: [0-9] [a-z]... 6 знаков под код + 3 - распределенка

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

мод тоже систему нагружает... юзал

правильно заданный вопрос.... :)))

Повторяю. Если документ записывается, сколько таблиц он блокирует? А если он блокирует их по-любому, то где разница?

любой обмен нагрузит. но всяко лучше использовать стандартное чем "велокат Гения"

по-разному можно нагрузить... мод-то каждое изменение анализирут и в траны пишет

Не будем рассматиривать документ, формирующий бух проводки. При записи ЛЮБОГО документа системы блокируется в обязательном порядке таблица журнала документов, таблица собственно самого документа, ну и, конечно же, таблицы регистров, по которым создает движения (необязательно.. документ может и не проводится). Таким образом, при  создании и записи ЛЮБОГО документа обязательному захвату подлежат всего лишь 2(ДВЕ) таблицы: таблица журнала документов и таблица документа... Внимание!!! Если есть и общие реквизиты документов, то при записи ЛЮБОГО документа требуется ОБЯЗАТЕЛЬНЫЙ захват 3(ТРЕХ) таблиц и с точки зрения производительности это существенно - захват 2-х таблиц в общем случае будет быстрее, чем трех.. и зависимость времени захвата, скорее всего, нелинейная..

Поделись травой или научи такой арифметике... КАКАЯ НАФИК ТРЕТЬЯ ТАБЛИЦА???

если подчинен, то еще 1SCRDOC

А какой график прироста размера базы после добавления общего реквизита длиной 9?

Третья таблица - это, пардон, какая?

кури ЖКК а не грибы

Не только по это причине, там еще и графы отборов...

и ты тудаже????

так ты ответь, и я пойду курить ЖКК, в которой, к слову, про структуру таблиц - ни слова...

ну да...

Естестсвенно...

Я, кажется, понял о какой третьей таблице речь... В посте автор пишет: "как было замечено в , общие реквизиты всех документов хранятся в одной физической таблице базы данных!!! И теперь, если идет массовый ввод документов, при записи каждого документа система будет ожидать монопольного захвата таблицы общих реквизитов - вследствие чего общая производительность системы упадет.. " ЗЫ. Осталось понять, что имеется в виду под "таблицей общих реквизитов"...

Зря ты это прочитал... Теперь он зохвает твой моск...

Снарк не гони.. сам ведь все понимаешь чем череваты общие..ведь не первый день замужем

что лучше: ввести 1 (!) общий реквизит или вешать модину?

ты, блин, не крути замужним органом. Ты отвечай или признавай, что спи**Ил.

Я не гоню... Гонит France в данном случае...

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

гонит только про 3 таблицу. а так в основном прав. у 7ки всегда были траблы с общими, почему в 8ке и отказались от них

МОД добавляет общий реквизит IDD в документы и в каждый справочник В доки - с отбором В спр-ки - с сортировкой И вообще - чо за тупняг тут? Я за общие реквизиты, т.к. лучше проиграть в одном месте но выиграть в десяти

В восьмерке меньше гемора по сбору информации

ты продолжаешь вертеть тем самым органом?

спасибо, я знаю

Таким образом, вопрос МОД вообще можно не рассматривать. Это я и сам могу сделать.

Вообщем реквизит с отбором длиной 9.

такой травой запросто так не делятся ... все было бы так хорошо, если бы не так плохо.. ну, нужно было ввязыватся с 67?? да, чтоб закрыть дискуссию - перестарался с количеством таблиц... PS France не гонит, он местами может заблуждатся.. так что , не надо про "гонит"..

я частности МОДа я не говорю про общие реквизиты, говорю про то что лучше использовать стандарты а не "велокаты"

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

если не урбд, то и 6 хватит.. хотя не сильно-то и важно)

а говорил, что не делятся... с уже поделился...

мод - стандарт???.. ух ты!

да не гонишь ты..где то лет 5 или больше пробегала инфа от 1Ски что не рекомендуется использовать Общие

а нет? докажи обратное

Однако они перекочевывают из релиза в релиз... в каждой типовой конфиге...

ты не крути, ты цЫтату даффай.

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

ну вот так отложилос...

больше под стол пешком ходить не буду?

Завести общий реквизит и при переносе искать документ и править его или заводить новый? Элементарно.

дак они тогда под стол пешком ходили

В ТиС 4 общих реквизита с отбором и один неорганниченной длины - и ведь работает.

мда... хорошая траффа... Ты по-русски говорить умеешь? Ты этта... абаснуй снижение производительности в случае необходимости иметь реквизит во всех документах...

дальше что.... изменю элемент справочника, причем с условием что они используется только в этом доке? давай на ГОРА свое решение