Здравствуйте, pagid_, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:

S>> Конечно. Но блокировать можно только определенные записи.
_>Правильно понимаю, что разговор про товарные документы и подбор партий с которых идет списание? Что мешало сделать транзакции по строчкам документа (наименованиям/товарным позициям или как они там у вас называются)
То есть не читатель

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

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

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

S>>Там же куча регистров (таблицы остатков движений) которые изменяются.
_>Тогда НС не зря про нормальные формы напоминал.
Угу. Он просто не сталкивался с нормальным учетом.
Например в бухгалтерии один план счетов в котором у каждого счета различный набор субконто и все это хранится в одной таблице.
С точки зрения программирования это тип Object или как в TS тип который может принимать несколько типов.

В 1С есть конечно много недостатков прежде всего из за универсальности нельзя использовать всю мощь SQL. Но можно Code First и Linq to EF на примере 1С версии 8.3. Часть II

Еще раз там где нужна скорость могут использоваться и другие системы. Но учет намного сложен. И написать универсальный учет невозможно.
Например никто не станет писать бухгалтерию, расчет ЗП. Там куча изменений в законодательстве, постоянные изменения конфигураций.

Поэтому как правило все сливается в определенные конфигурации с Бух учетом зарплатой итд.

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

А так в 1С есть различные регистры с которыми можно быстро работать. Я в свое время занимался автозапчастями с сотней миллионами прайсами. Правда использовал прямой SQL для записи в регистры сведений.
Да в 1С надо избегать подписок при изменении регистров.

Здравствуйте, pagid_, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:

S>> Конечно. Но блокировать можно только определенные записи.
_>Правильно понимаю, что разговор про товарные документы и подбор партий с которых идет списание? Что мешало сделать транзакции по строчкам документа (наименованиям/товарным позициям или как они там у вас называются)
То есть не читатель

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

Но как правило нужно еще учет по складам, местам хранения, резервам, взаиморасчетам.
По алкашке например это помарочный учет, коробки итд.
И все это должно быть в одной транзакции.
Набивают документы и сотрудники, и клиенты делают заказы через вэб интерфейс и апи. Контроль нужен по всему документу.
Можно конечно схемы придумать, что если нет на остатках то корректировать в момент проведения.
Но построчно делать транзакции это более ресурсоемко, так как в итоге придется сделать больше запросов вместо одного по номенклатуре документа (остатки, резервы), придется по каждой строке документа.
В любом случае так можно сделать. Любой каприз.
Можно делать записи в регистры вне модуля проведения.

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

S>>Там же куча регистров (таблицы остатков движений) которые изменяются.
_>Тогда НС не зря про нормальные формы напоминал.
Угу. Он просто не сталкивался с нормальным учетом.
Например в бухгалтерии один план счетов в котором у каждого счета различный набор субконто и все это хранится в одной таблице.
С точки зрения программирования это тип Object или как в TS тип который может принимать несколько типов.

В 1С есть конечно много недостатков прежде всего из за универсальности нельзя использовать всю мощь SQL. Но можно Code First и Linq to EF на примере 1С версии 8.3. Часть II

Еще раз там где нужна скорость могут использоваться и другие системы. Но учет намного сложен. И написать универсальный учет невозможно.
Например никто не станет писать бухгалтерию, расчет ЗП. Там куча изменений в законодательстве, постоянные изменения конфигураций.

Поэтому как правило все сливается в определенные конфигурации с Бух учетом зарплатой итд.

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

А так в 1С есть различные регистры с которыми можно быстро работать. Я в свое время занимался автозапчастями с сотней миллионами прайсами. Правда использовал прямой SQL для записи в регистры сведений.
Да в 1С надо избегать подписок при изменении регистров.