Может ли разбиение файлов .MDB на сегменты помочь со стабильностью?

Question

Является ли это реалистичным решением проблем, связанных с большими .mdb файлами:

• разбить большой .mdb файл на меньшие .mdb файлы
• есть один «центральный» .mdb, содержащий ссылки на таблицы в меньшем .mdb файлы

Насколько легко было бы сделать это изменение для .mdb поддерживаемого приложения VB?

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

Answer 1

Редактировать начало
Краткий ответ: «Нет, это не решит проблемы большой базы данных».

Возможно, вы сможете преодолеть ограничение размера БД (~ 2 ГБ) с помощью этого трюка, но я никогда не проверял его.

Как правило, при работе с большими базами данных MS Access возникают проблемы со скоростью и повреждением данных.

Скорость
Это поможет со скоростью? У вас остается тот же объем данных для запроса и поиска, и тот же алгоритм. Итак, все, что вы делаете, это добавляете накладные расходы, связанные с открытием нескольких файлов на запрос. Поэтому я ожидаю, что это будет медленнее.

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

1. более быстрые диски
2. положить MDB на RAID (анекдотически RAID-1,0 может быть быстрее)
3. разделите MDB (как вы предлагаете) на несколько MDB и поместите их на отдельные диски (возможно, даже на отдельные контроллеры).

(насколько хорошо это будет работать на практике по сравнению с теорией, я не могу вам сказать - если бы я выполнял такую ​​большую работу, я бы все же решил переключать двигатели БД)

Повреждение данных
MS Access имеет заслуженную репутацию за повреждение данных. Честно говоря, у меня не было такого раньше со мной. Это может быть потому, что я научился не использовать его для чего-то большого; или это может быть потому, что MS приложил много усилий, чтобы решить эти проблемы; или, скорее, комбинация обоих.

Основные виновники в повреждении данных:

1. Аппаратное обеспечение: например, космические лучи, электрические помехи, ненадежные накопители, ненадежная память и ненадежные процессоры - я подозреваю, что MS Access не так хорошо обрабатывает и исправляет ошибки, как другие базы данных.
2. Сети: множество коллизий в насыщенной сети может запутать MS Access и убедить его закодировать важные записи; так же может неоптимально реализованные сетевые протоколы. TCP / IP хорош, но не непобедим.
3. Программное обеспечение: Как я уже говорил, MS проделала большую работу над MS Access на протяжении многих лет, если вы не обновляете свои патчи (MS Office и ОС), будьте в курсе. Проблемы обычно возникают, когда вы достигаете таких крайностей, как ограничение в 2 ГБ (некоторые ошибки сложно проверить и они не проявят себя, за исключением крайних случаев, что снижает вероятность того, что их увидят или исправят, если только мотивированный пользователь не сообщит МС).

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

Редактировать Конец

Лучше всего было бы перейти на что-то вроде MS SQL Server. Вы можете начать с миграции ваших данных, а затем связать с ними один MDB. Вы получаете стабильность SQL-сервера, и большая часть (если не все ) вашего кода все еще должна работать.

Как только вы это сделаете, вы можете вместо этого начать миграцию ваших приложений VB на наш SQL Server.

Answer 2

Если у вас больше данных, чем умещается в одном MDB, вам следует использовать другой механизм базы данных.

Одна из основных проблем, которую вы должны учитывать, заключается в том, что вы не можете обеспечить ссылочную целостность между таблицами, хранящимися в разных MDB. Это должно быть шоу-стопором для любой реальной базы данных.

Если это не так, то, вероятно, у вас, во-первых, нет правильной схемы.

Answer 3

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

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

У меня недавно были очень хорошие результаты при переносе системы Access с MDB на MySQL. По крайней мере, 95% кода функционировали без изменений, а из оставшихся 5% большинство было простым, лишь с несколькими ограниченными областями, где требовались значительные усилия. Если у вас неаккуратный код (не закрывающий соединения или не освобождающий объекты), вам нужно будет это исправить, но в целом я был удивлен, насколько безболезненным был этот подход. Конечно, я настоятельно рекомендую, чтобы, если причина, по которой вы не хотите переходить на серверную часть базы данных, связана с расходами, вам не следует пытаться манипулировать файлами .mdb и вместо этого переходить на более надежное решение для базы данных.

Answer 4

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

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