Программист 1сNitro_Junkieпропущено...


А кстати интересно как? Я правильно понимаю, что у вас явно MS SQL в режиме версионника с управляемыми блокировками?

Просто я все никак не могу понять, как можно на СЛОЖНОЙ системе ВРУЧНУЮ оценить все возможные варианты конкурентного доступа и правильно синхронизировать их. Потому как даже с Write-Write блокировками достаточно проблем, а с Read-Write... Два варианта а) если слишком большие блокировки - аааа... у всех все висит, б) если слишком маленькие - а че у меня тут суммы не сходятся...Управляемые блокировки в разрезе складов. Каждая аптека - свой склад. Можно одновременно проводить все документы.

У меня не 200 складов . Поэтому просто сделано максимальное быстрое проведение. Даже если бы были документы по 1 в 0.1 секунды, все было бы нормально.

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

Ну и вы я так понимаю в режиме версионника работаете или блокировочник в read commited обычный?

Последний выдох ГПЖNitro_JunkieНу и вы я так понимаю в режиме версионника работаете или блокировочник в read commited обычный?

а проблема в чем?

8.3 понимает read commit snapshot из коробки (с учетом совместимости)

Ну READ COMMITED SNAPSHOT - это по сути забиваем на целостность. Будь что будет - там где заметим конкурентность, если повезет все будет ОК. Если нет, то сразу, а почему она дала провести, а почему сумма не сходится и т.п.

Последний выдох ГПЖNitro_JunkieНу READ COMMITED SNAPSHOT - это по сути забиваем на целостность.

почему забиваем на целостность?

снепшот дает "целостность". но в пределах некой версии, которую в данный момент какая-то падла может менять

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

Программист 1сИ пусть Ваш супер сложный расчет разрешения проведения займет 0,1 секунды.

Ну это если у вас пришло-ушло осталось. А если у вас десяток интегрированных модулей, там одних проверок и агрегаций > 200. Вон даже в УТ если зайти на demo.1c.ru, обычное поступление на 3 позиции проводится 3 секунды минимум, а там база из 100 записей.

Последний выдох ГПЖснепшот убирает shared на чтение, но exclusive на запись (или если "попросить" об этом) - никуда не делся

При Snapshot чтение вообще в блокировках не учавствует. Как класс.

На самом деле именно Read Commited приводит к неповторяющимся чтениям. По идее если включать полностью SERIALIZABLE режим, то их не будет (но вопрос насколько сам 1С умеет работать в таком режиме с управляемыми и внутренними блокировками в регистрах)

Последний выдох ГПЖNitro_JunkieТо есть если кто-то запустил перепроведение, то другая транзакция которая читает данные этого перепроведения может получить данные сначала без учета его, а при следующем чтении уже с учетом. Как в этом случае вообще что-то можно проверять, обновлять?

ну такие вещи "заворачивают" в единые транзакции

Не понял, если честно, что именно "заворачивают"?

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

MironicoПочитал я коменты и чет страшно стало.
Опыта для написания такого монстра маловато.

На самом деле мы немного преувеличиваем проблему. Можно действительно перевести 1С в режим "будь что будет" (READ COMMITED SNAPSHOT) и теоретически наверное в одной базе работать будет. Да иногда будет что-то плыть, ну будете заходить перерасчитывать, вручную подгонять. Я думаю это все в свое время с файл-сервером проходили и ничего выжили как-то.

Программист 1сВы не путайте обычную ут, с модернизированной. А еще демо-сервер с реальным сервером.
А в чем разница? Особенно с сервером, или 1Са денех мало нормальный сервер взять. На том же ovh за 1000 баксов в месяц?

Программист 1сА что за 200 проверок? Допустим 10 по договору, еще 5 по остаткам. Что за остальные проверки?
200 проверок я имел ввиду все - создание агрегированных объектов (например строка накладной создает партию, позицию расценки, позицию поставки, так как в постсовке invoice'ы объединены с shipment'ами, штук 10 записей в регистрах и т.п.), перерасчет агрегированных показателей (вроде тех же сумм по регистрам + агрегаций для оперативной работы), записи логов (всего и вся, в сложной системе без этого никак, все друг на друга начинают валить). Ну и куча всяких мелких проверок \ трансформаций - вроде приведений к регистрам серий, номеров, или проверки что везде все задано, и всякая херня типа: 'Розничная сумма для строки поступления на цех должна совпадать с розничной суммой строки перемещения на цех', 'Покупатель строки основания должен соответствовать Организации склада списания' (таких я насчитал > 30)

Тут еще вопрос, что очень много данных надо денормализовывать чтобы иметь составные индексы. Скажем Склад + Дата + Прайс, потому как в нормализованном виде у вас при наличии 50 складов все будет ложиться (понятно что когда все не в одной базе таких проблем нет)

Кроме договоров, есть еще ассортименты, расценка, сертификация, госрегистрация, таможенное оформление, ну и все что связано с оперативным управлением закупками (где нужно много оперативных данных), это навскидку. Может конечно не 200, но порядок такой. И да, понятно что уложится в секунду можно (мы например укладываемся) но дьявол в деталях:

Бросайте все Ваши проверки в 1 запрос. Скорость выполнения запроса будет 3 секунды?

Вот это первая деталь. Потому как в таком случае нахрена вообще 1С или любой другой ORM фреймворк. То есть да можно делать все чисто в SQL парадигме, но с точки зрения поддержки и разработки это песец, причем фееричный. Причем ладно если еще можно сделать чтобы для ОДНОЙ операции был 1 запрос для ВСЕХ объектов (хотя даже это на ORM / 1С уже редкий геморрой, так как все же основные варианты использования это For и Документ.Цена=Товар.Цена, то есть ОДНА операция/ОДИН объект). Но для ВСЕХ операций и ВСЕХ объектов - 1 запрос, это очень дорого и не удобно. Если вы видели код систем, которые стремятся к этому, то не знаю как у вас, а у меня чуть кровь из глаз не лилась.

А вторая деталь, что делать с изменениями данных. Проверки скажем на остаток >0 при оперативном проведении это прекрасно. А вот что делать при изменении уже введенных документов, это куда веселее. Там нужна туча проверок на конкурентный доступ (скажем чтобы 2 человека одновременно не меняли одни и те же данные), но при этом желательно чтобы одновременно могли менять одни люди цены, а вторые скажем сертификаты.

В 1Се для изменений придумали проведение \ распроведение. Но вот тут я честно говоря вот чего не понимаю. Если у меня был приход на 5, расход на 5, а я меняю приход на 4. Что в этой идеологии будет? Она ругнется на распроведении (но тогда и 6 на 5 изменить нельзя будет) ? Или при проведении (но тогда непонятно, по идее она будет видеть что мы с -5 меняем на -1 и должна пустить). Может кто из местных 1Сцев подскажет?

Ну и тоже самое непонятно, что делать с теми же партиями (в идеологии проведение \ распроведение). Понятно, что сам 1С предлагают РАУЗ (типа вы просто "неправильно его держите"), но скажем в Беларуси в опте ОБЯЗАТЕЛЕН партионный учет. Ни один бухгалтер не согласится на его отсутствие, более того многие устраивают панику если по какой-то партии остаток <0.

kihorNitro_JunkieВ 1Се для изменений придумали проведение \ распроведение. Но вот тут я честно говоря вот чего не понимаю. Если у меня был приход на 5, расход на 5, а я меняю приход на 4. Что в этой идеологии будет? Она ругнется на распроведении (но тогда и 6 на 5 изменить нельзя будет) ? Или при проведении (но тогда непонятно, по идее она будет видеть что мы с -5 меняем на -1 и должна пустить). Может кто из местных 1Сцев подскажет?


Если я правильно понял Ваш вопрос, то при изменения прихода с 5 на 4 образуются отрицательные остатки. Это нужно просто контролировать периодически просматривая отчет об остатках. Я пока не сталкивался с тем, чтобы это была бы какая-то серьезная проблема. Если сотрудники вводят документы своевременно и на основе реальных операций, то проблемы это не составляет.

Безусловно. В идеальном мире. А на практике, млин у меня 200 отрицательных остатков по партиям. Что делать?!! Нас всех посадят !!!. А там идут цепочки отрицательных остатков. То есть товар пришел за день продался, ушел. В итоге все партии сместились, а руками сводить часы работы да и некому.

Причем забавляет логика пользователей. Как нам рассказывали при внедрении, был у них случай в предыдущей программе: пользователь звонит говорит не могу провести. Ей отвечают будем разбираться (пока учет в разнос не пошел), звонят через час объяснить, что она то ли не то списывает, то ли не оттуда. А он отвечает, а не все нормально я нашла как обойти. Она провела с другим складом, потом поменяла товар, там еще пару шаманских действий сделала, в таком случае проверки уже не было, и она все провела. Дебилы, б...

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

Последний выдох ГПЖпоследовательность "свалится". при ее восстановлении партии перераспределятся

было:
"+" партия 1 +4
"-" партия 1 -4

стало:
"+" партия 1 +3
"-" партия 1 -4

после восстановления станет

"+" партия 1 +3
"-" партия 1 -3
"-" партия 1 -1


но это при наличии естественно

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

Но меняя вообще вопрос в принципе с остатками интересовал. То есть фиг с ними с партиями. Есть приход по товару - 5 штук и расход 5 штук. Как должно происходить изменение прихода на 4 штуки и проверка что остаток не меньше 0. То есть 6 приход - 5 расход должно дать изменить на 5 - 5. А 5 приход - 5 расход на 4-5 не дать.