В нашем текущем проекте клиенты будут отправлять сборник сложных / вложенных сообщений в нашу систему. Частота этих сообщений составляет ок. 1000-2000 мсг / с.

Эти сложные объекты содержат данные транзакции (которые будут добавлены), а также основные данные (которые будут добавлены, если они не найдены). Но вместо передачи идентификаторов основных данных клиент передает столбец «имя».

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

После разрешения идентификаторов основных данных система вставляет транзакционные данные в базу данных SQL Server (используя идентификаторы основных данных). Количество главных объектов на сообщение составляет около 15-20.

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

Сначала мы можем разрешить основные идентификаторы из нашего кода C # (и вставить основные данные, если они не найдены) и сохранить эти идентификаторы в кеше C #. Как только все идентификаторы разрешены, мы можем массово вставить транзакционные данные, используяSqlBulkCopy учебный класс. Мы можем обратиться к базе данных 15 раз, чтобы получить идентификаторы для различных объектов, а затем еще раз нажать на базу данных, чтобы вставить окончательные данные. Мы можем использовать то же соединение, которое закроет его после выполнения всей этой обработки.

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

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

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

Одно такое сообщение будет содержать информацию об одном продукте (его основные данные) и подробности его цены (данные о транзакциях) от разных поставщиков:

Основные данные (которые необходимо добавить, если они не найдены)

Название продукта: ABC, ProductCateory: XYZ, Производитель: XXX и некоторые другие детали (количество свойств находится в диапазоне 15-20).

Данные транзакции (которые будут всегда добавляться)

Название поставщика: A, ListPrice: XXX, Скидка: XXX

Название поставщика: B, ListPrice: XXX, Скидка: XXX

Название поставщика: C, ListPrice: XXX, Скидка: XXX

Название поставщика: D, ListPrice: XXX, Скидка: XXX

Большая часть информации о основных данных останется неизменной для сообщения, принадлежащего одному продукту (и будет меняться реже), но данные транзакции всегда будут колебаться. Таким образом, система проверит, существует ли продукт «XXX» в системе или нет. Если нет, проверьте, существует ли «Категория», упомянутая в этом продукте. Если нет, он вставит новую запись для категории, а затем для продукта. Это будет сделано для производителя и других основных данных.

Несколько поставщиков будут отправлять данные о нескольких продуктах (2000-5000) одновременно.

Итак, предположим, что у нас 1000 поставщиков, каждый поставщик отправляет данные о 10-15 различных продуктах. Через каждые 2-3 секунды каждый поставщик отправляет нам обновления цен на эти 10 продуктов. Он может начать отправлять данные о новых продуктах, но это будет не очень часто.