Файл базы данных MDB перемещен вне сайта

Вы не вдаваетесь в подробности о том, что ваша заявка или каковы ваши отношения с клиентом. Итак, вот мои отзывы, основанные на прошлом опыте (и одном конкретном случае), имея в виду следующее:

1) Вы являетесь разработчиком приложения с продуктом, проданным клиенту, будь то для вашей собственной компании или по контракту (вы не являетесь внутренним разработчиком).

2) Ваше приложение использует то, что в основном является движком Access за внешним интерфейсом.

3) Ваш клиент платит вам за это многопользовательское приложение, используя файл MDB, который теперь хранится в общей папке Windows, к которой обращаются несколько клиентских приложений.

4) У вашего клиента есть какой-то ИТ-отдел, который хотя бы минимально знаком с базами данных, и если нет, он быстро поймет это.

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

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

Поставщик настоял, чтобы это приложение работало нормально в других (похожих) организациях, поэтому проблема была в нашей сети или системах. Мы заменили системы. Они настаивали на установке мини-коммутатора в соседней комнате, чтобы помочь "изолировать" трафик, потому что наш трафик был слишком высок в сети, вызывая проблемы с задержкой (даже если только у их приложения были проблемы, ничто иное не показывало явных признаков проблем с задержкой). Затем они обвинили питание, настаивая на том, чтобы мы поставили ИБП на рабочие станции и их мини-коммутаторы для кондиционирования питания. Каждый раз случайный сбой будет возникать снова.

Мы прошли через все эти обручи, которые разработчики настаивали, чтобы исправить это, просто чтобы показать им, что НЕТ, это НЕ ПРОБЛЕМА. Проблема была довольно очевидной. Двухминутное Google сообщения об ошибке показало, что это была проблема с блокировкой файлов, и быстрое изучение их приложения показало, что он использует базу данных MDB; в основном приложение было внешним интерфейсом для механизма доступа. Файлы MDB в общей папке просто не предназначены для многопользовательского доступа. Когда выполнялось достаточное количество транзакций, в конечном итоге две наши клиентские рабочие станции столкнулись с приложением базы данных в точке, где оно не могло должным образом заблокировать запись для обновления, и это приводило к ошибке.

Я не программист, я не администратор БД, это именно то, что я нашел в исследованиях, и у меня было много людей, согласных. Изменилась ли эта ситуация в более поздних версиях? Я не знаю. Но я знаю, что нашел много людей, которые просто сказали, что делают это неправильно. "Когда у вас есть несколько клиентов в базе данных, используйте решение для сетевой базы данных, разработанное для обработки многопользовательского доступа". Бабушка имеет доступ к рецептам печенья. Не очень хорошо для обработки 20 пользователей, которым требуется целостность транзакций одновременно по сети.

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

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

Далее, файловая база данных в основном полагается на другие механизмы, чтобы помочь защитить ее в транзакциях. Настоящий администратор БД мог бы исправить меня здесь, но в то время, насколько я понял, эта база данных, к которой обращались несколько клиентов по сети на сервере, имела дело с файловой системой, абстрактной файловой системой общего доступа к файлам (общий доступ Windows) и механизмом это не обрабатывало правильную блокировку базы данных для нескольких пользователей одновременно."Истинные" базы данных (MySQL, MSSQL, MongoDB и т. Д.) Справляются с этим лучше, потому что они созданы для этого. Доступ отлично подходит для отслеживания ваших рецептов и коллекций фильмов. Не используйте его для предприятий, работающих с точками продаж или большими базами данных службы поддержки.

Почему это работает в локальной сети? Если вы скажете им (и у них есть ИТ-отдел с половиной остроумия среди них), что все базы данных должны быть в локальной сети для правильной работы, они, вероятно, зададутся вопросом о том, как вы относитесь к базам данных, к которым вы предъявляете такие требования, если вы не знали для факта, что они настраивают свою WAN с эквивалентом модемов Хейса по линиям POTS. Правда вполне может состоять в том, что использование файла MDB шатко и подвержено ошибкам; хранение его в локальной сети снижает некоторые проблемы, связанные с конфликтами, ниже порогового значения, в котором оно (обычно) работает. Если они увеличат количество клиентских приложений, использующих эту базу данных, даже в локальной сети, вы, вероятно, увеличите количество "случайных проблем", возникающих с приложением, и их ИТ-отдел будет тихо ругать вас за то, что у вас есть дрянное приложение каждый раз они должны что-то перезапустить или иметь дело с вашим приложением, когда оно имеет сбой.

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

Не говоря уже о том, что если они реорганизовали свои общие серверные ресурсы по причинам, известным внутри компании, но ваше приложение должно быть особенным, что-то еще, чтобы по какой-то причине было задокументировано или обработано по-другому, ИТ-персонал не будет благосклонно рассматривать ваше приложение. Если вы хотите хороших отношений с ними, зачем им противодействовать?

(Кроме того... если у них есть подключающиеся офисы WAN, вы уверены, что удаленным пользователям никогда не понадобится использовать ваш продукт? Или они могут перевести людей, чтобы некоторые удаленные пользователи использовали ваше приложение? Тогда у вас будет сплит-сеть вопрос всплывает снова и снова.)

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

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

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

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

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

Если у вас есть проблемы, вам нужно будет собрать доказательства (количество раз, когда WAN-соединение отключалось, сколько раз медленная производительность влияла на приложение, общее время, затрачиваемое на выполнение действия X по локальной сети в сравнении с WAN и т. Д.)

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

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

Несмотря на все обсуждения, мой ответ остается прежним: вы не можете сформулировать политику, вы не должны сравнивать доступ на основе файлов MDB с реальным доступом к базе данных для таких вещей, как Oracle DB2, и вам лучше всего собрать реальные вещественные доказательства и представить тот.