Базы данных MS Access в медленной сети: быстрее ли разделить серверные части?

Question

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

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

Это вменяемое заключение? Я неправильно понимаю много? Я что-то упустил?

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

Буду признателен за любые мысли или (достаточно обоснованные) критические замечания.

Answer 1

Это распространенное недоразумение:

MS Access должен извлечь файл всей базы данных на локальный компьютер, чтобы сделать какие-либо запросы или обновления

Рассмотрим этот запрос:

SELECT first_name, last_name
FROM Employees
WHERE EmpID = 27;

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

Без индекса EmpID механизм будет выполнять полное сканирование таблицы таблицы Employees, то есть ему придется читать каждую строку таблицы, чтобы определить, какие из них соответствуют значениям EmpID.

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

Вы правы, что есть издержки для соединений с внутренними файлами базы данных. Движок должен управлять файлом блокировки для каждой базы данных. Я не знаю масштабы этого воздействия. Если бы это был я, я бы создал новую внутреннюю базу данных и импортировал бы таблицы из других. Затем сделайте копию внешнего интерфейса и снова свяжите его с внутренними таблицами. Это даст вам возможность непосредственно изучить влияние на производительность.

Мне кажется, что реляционная целостность должна быть сильным аргументом для объединения таблиц в единый сервер.

Что касается блокировки, вам никогда не нужно блокировать всю внутреннюю базу данных для рутинных операций DML (INSERT, UPDATE, DELETE). Базовый механизм базы данных поддерживает более детальную блокировку. Также пессимистическая или оппортунистическая блокировка - независимо от того, происходит ли блокировка после начала редактирования строки или откладывается до сохранения измененной строки.

На самом деле «медленная сеть» может быть самой большой проблемой, если медленная означает беспроводную сеть. Доступ безопасен только в проводной локальной сети.

Редактировать : Доступ не подходит для сетевой среды WAN. См. эту страницу Альберта Д. Каллала.

Answer 2

мс доступ не подходит для использования в локальной сети или глобальной сети, которые, конечно, имеют более низкую скорость. решение состоит в том, чтобы использовать базу данных клиент-сервер, такую ​​как Ms SQL Server или MySQL. MS SQL Server намного лучше, чем My SQL, но это не бесплатно. Рассмотрим Ms SQL-сервер для крупномасштабных проектов. Я снова сказал, что доступ к MS хорош только для 1 компьютера, а не для компьютерной сети.