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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Использование передовых технологий в простых задачах - дорогостоящий путь, и не всегда ответ!

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Насколько я понимаю, если бы мы были используя sql, время поиска не будет подняться, как стол становится больше, потому что весь .mdb не должен быть отправляется по сети каждый раз. Является это правильно?

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

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

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

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

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