Артемий

Решение определяется размером списка. Если размер такой, что возникает сильный своп по оперативной памяти, то надо работать с выборками из sql. По любому все в экран не влезет и висанет.

Координатор распределенных транзакций, а вообще говоря наверно блокчейн можно использовать)

В 1с есть компонента "Расчет" на ней можно такие задачи решать эффективно.

cassandra.apache.org

1. составить бизнес-требования к системе
   
2. написать ТЗ
   
3. заказать проект системы
   

А в целом возьмите 1С и не изобретайте велосипеды.

Самый простой вариант подключиться напрямую к базе из 1С и работать с данными. Я oledb когда то использовал - не знаю что сейчас актуально. Чтобы сделать решение кросс-платформенным, можно сделать php прокси скрипт, чтобы по HTTP пробрасывать SQL.

Наверно Вам поможет распределенное хранение и параллельная обработка данных

Это проблема решаеться через проектирование системы и ведение документации по разработке.

Для этого предназначены внешние ключи и связи один ко многим и один к одному.

Самое простое - добавить второй счетчик и построить логику на двух счетчиках.

Вы можете использовать очередь сообщений в любой реализации для асинхронной работы.

Если Вы углубляетесь в тему авторизации, то на мой взгляд оптимальное решение LDAP+SASL на данный момент. Конечно можно и в Kerberos углубиться, но мне думаю это совсем не тривиально

Надо создать таблицу с операциями по балансу и по ней баланс считать.

Либо SQL+Join, либо NoSQL с эмуляцией join или дублированием и синхронизацией данных. В целом в Mongo есть https://docs.mongodb.com/manual/reference/operator...

Задача решается через OLTP с OLAP. Как Вы будете хранить исходные данные от пользователя для начислений и выплат и обрабатывать транзакции это уже другой вопрос. А для учета взаиморасчетов с сотрудниками делаете таблицу транзакций по взаиморасчетам например: (Дата, Сотрудник, Начисление/Выплата, Сумма) и таблицу агрегата суммы расчетов например: (Месяц,Сотрудник,Сумма начислений, Сумма выплат,Сальдо конечное). Дальше соответственно при записи данных от пользователя(OLTP) создаете транзакцию и обновляете для нее агрегаты по месяцам с сальдо(OLAP).

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

Думаю надо копать в сторону WebRTC, т.к. вы пытаетесь построить систему реального времени. Но можно требования к системе изменить и жизнь упроститься.
Вообще говоря есть предикат ЛотЗавершен(лот,{заявки})={true|false}. А как его реализовывать это уже второй вопрос.

KLADR

Дело то во времени происходит. Или Вы один раз на каждое место планируете резерв ставить?

R