Должен ли я выступать за переход от доступа к (моему) sql

Question

У нас есть приложение MFC для Windows, которое написано в отношении базы данных доступа на сервере компании. ДБ не такой большой: 19 МБ. В настоящее время доступно не более 2-3 пользователей. Он используется в заводской среде, где скорость доступа (или ее отсутствие) по интрасети становится заметной, поскольку она является частью времени изготовления наших виджетов.

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

Мы сейчас переделываем другие части этого приложения, и было бы неплохо перейти на другой db, если мы это сделаем.

Насколько я понимаю, если бы мы использовали sql, время поиска не увеличивалось бы, поскольку таблица стала больше, потому что весь .mdb не нужно отправлять по сети каждый раз. Это верно? Кто-нибудь знает, может ли это стоить того, чтобы перейти к проблеме (времени и денег) перехода на новый db, или просто добавить дополнительные функции для приложения, которое у нас есть сейчас, и, возможно, автоматически очистить старые записи время от времени, и добавить дополнительные возможности в приложение, чтобы получить старые записи, когда это необходимо?

Спасибо за любую мудрость вы можете поделиться ..

Answer 1

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

1. ИНДЕКСЫ. Если ваши запросы начать замедление, убедитесь, что у вас есть соответствующие индексы http://support.microsoft.com/kb/304272
   
2. Ваше сетевое соединение между компьютерами быстро. Может быть, обновление до гигабитных карт и маршрутизаторов? Возможно поставить БД на диске SCSI (RAID 10 для скорости и избыточности)
   

Бросив передовые технологии простых задач является дорогостоящим способом пойти и не всегда ответ!

Answer 2

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

Эта общая идея применима практически для всех баз данных. Идея базы данных состоит в том, чтобы отделить ваше приложение от фактических данных. Данные хранятся на сервере базы данных. В вашей заявке нет.

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

Да. Предлагая это много раз. Это дорого. Это сложно. Ваша база данных MS-Access никогда не станет лучше или быстрее.

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

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

Answer 3

Я бы, вероятно, перешел на Microsoft SQL Server 2008 R2 Express Edition (бесплатно) или MySQL (бесплатно), если есть и финансирование, и время для ввода уровня доступа к данным. Поскольку вы будете делать запросы удаленного сервера и не работать с данными на локальной рабочей станции, этот шаг очень связан с точки зрения разработки.

Однако вы должны проанализировать, является ли это более эффективным с точки зрения затрат для выполнения вашего архивного процесса ежеквартально или ежемесячно, и просто переместите базу данных архива в SQL Server 2008 R2 Express Edition. (Вы можете установить клиентские инструменты Microsoft SQL Server Management Studio на рабочих станциях и запросить архивную базу данных для более быстрого получения отчетов о исторических данных без перезаписи всего производственного приложения, аналогичные решения существуют для использования MySQL или других OSS/бесплатных РСУБД).

Answer 4

Вместо того, чтобы отправлять БД по сети клиенту, а затем выполнять запросы, вместо этого вы можете написать небольшую обертку на сервере, которая обрабатывает запросы, просматривает результат в БД доступа (используя SQL + драйвер доступа ODBC) и возвращает результат. Это позволяет избежать накладных расходов большой миграции, которая вам может не понадобиться, и по-прежнему избавляется от основной проблемы, с которой сталкиваются пользователи.

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

Answer 5

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

Как уже упоминалось, тратят время + деньги на настройку и обслуживание, а затем у кого-то есть поддержка и поддержка и поддержка этого сервера базы данных, безусловно, здесь. Однако имейте в виду, что простое перенос приложения JET на сервер sql во многих случаях будет работать медленнее, и на самом деле сервер sql медленнее, чем JET, когда сеть не задействована.

Итак, я бы потратил некоторое время, чтобы выяснить, почему все так сильно замедляется, а также проверять, как настроено индексирование.

Итак, имейте в виду, что это чистый фольклор и миф, что все таблицы и вся база данных передаются по сети. Эта концепция ТОЛЬКО ДЛЯ большинства людей, которые действительно не имеют компьютерной подготовки, и не знают и не понимают, как работает механизм данных JET.

Answer 6

У меня есть чиллеры с базами данных 300 МБ, хотя они должны быть увеличены до SQL Server по другим причинам. 19 Mb относительно невелико. Если производительность настолько плоха, что архивирование ускоряет работу, проверьте индексы на таблицы для всех полей сортировки и выбора. Альберт дал вам хороший URL, чтобы проверить.

Все файлы MDB не спускаются по проводу. Если вам не хватает индексов.