Веб-сервисы и параллелизм базы данных

Question

Я создаю клиентское приложение .NET (C #, WinForms), которое использует веб-сервис для взаимодействия с базой данных. Клиент будет запускаться из удаленных мест с использованием WAN или VPN, поэтому идея использования веб-службы вместо прямого доступа к базе данных.

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

Как лучше всего подойти к этому?

Answer 1

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

Но если вы передаете клиенту что-то вроде таблицы данных и хотите избежать меток времени, вы можете выполнить проверку параллелизма, сравнивая поле за полем. Мастера Table Adapter генерируют этот тип проверки параллелизма по умолчанию, если вы запрашиваете оптимистическую проверку параллелизма.

Answer 2

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

Answer 3

Если ваши коллизии происходят достаточно редко, чтобы их можно было разрешить вручную, простое решение - добавить триггер обновления, который копирует значения предварительного обновления строки в таблицу аудита. Таким образом, самая последняя запись является «победителем», но при перезаписи данные никогда не теряются, и администратор может восстановить более раннее состояние строки или даже объединить их.

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