MS Access (MDB) параллелизм - PullRequest
       43

MS Access (MDB) параллелизм

34 голосов
/ 29 марта 2009

Для небольшого проекта мне нужно использовать простую базу данных с очень легкими требованиями: несколько таблиц, всего не более нескольких тысяч записей, 2 или 3 пользователя. Я работаю в среде .NET.

Поскольку сервер базы данных (даже эти выпуски Express) в этом случае выглядит огромным перебором, очень простая база данных MDB может удовлетворить большинство требований. Я, однако, обеспокоен параллелизмом. Моя идея состоит в том, чтобы поместить файл .mdb в общую сетевую папку и позволить пользователям получать доступ к этому файлу со своих клиентов на основе .NET. БД в основном предназначена для операций только для чтения, но пользователям иногда также необходимо обновлять / удалять записи. Если это будет невозможно в то время (из-за блокировки БД или чего-то еще), я могу задержать обновления на клиенте и обработать их позже.

Сам вопрос звучит так:

  • Как обрабатываются параллельные чтения в MDB?
  • Как обрабатываются одновременные обновления / удаления в MDB?
  • Существует ли концепция блокировок и как ее использовать в приложении .NET?
  • Является ли размещение файла MDB на сетевом ресурсе хорошей или ужасной идеей?

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

РЕДАКТИРОВАТЬ : Это может быть моим плохим описанием проблемы, но большинство ответов, кажется, советуют использовать полноценный сервер БД. Я понимаю различия и преимущества установки сервера и фактически реализовал значительное количество проектов на MSSQL и Oracle. В этом вопросе, однако, я касаюсь только доступа и его проблем параллелизма, поэтому, пожалуйста, не предлагайте db-сервер.

Спасибо за вашу помощь.

Ответы [ 11 ]

0 голосов
/ 29 марта 2009

Пожалуйста, не используйте Access для многопользовательского сценария.

Я только что пережил две недели боли, потому что мой предшественник в проекте выбрал Access в качестве бэк-энда.

Конкретные причины:

  • Нет такой вещи, как Linq-to-Access
  • В Access есть множество причуд, таких как зависимости от порядка добавления параметров к командам, которые потребуются вам для отладки
  • Доступ не масштабируется
  • Обновления базы данных являются рутиной по сравнению с использованием SQL Server
...