Большой клиент, использующий мое приложение на основе MDB, переместил файл MDB за пределы площадки, так что мое приложение подключается к нему через WAN.
Как я могу убедить их поместить файл MDB обратно в локальную сеть, чтобы приложение могло работать надежно?
Могу ли я сказать, что все базы данных должны находиться в локальной сети, независимо от того, какая база данных? Могу ли я сказать, что SQL-серверы, Oracle и т. Д. Все работают в локальной сети, а не в глобальной сети, по соображениям надежности?
Вы не вникаете в подробности того, что представляет собой ваше приложение или каковы ваши отношения с клиентом. Итак, вот мой отзыв, основанный на прошлом опыте (и, в частности, на одном инциденте), имея в виду следующее:
1) Вы разработчик приложения, продукт которого продан клиенту для вашей компании или по контракту (вы не являетесь внутренним разработчиком).
2) Ваше приложение использует то, что в основном является движком доступа за внешним интерфейсом.
3) Ваш клиент платит вам за это многопользовательское приложение, используя файл MDB, который теперь хранится в общей папке Windows, к которой имеют доступ несколько клиентских приложений.
4) У вашего клиента есть какой-то ИТ-отдел, который хоть немного знаком с базами данных, а если нет, то быстро поймет.
5) Единственная проблема вашего клиента связана с вашим приложением по этому каналу WAN (то есть приличная пропускная способность, в основном надежная, работает для других приложений по большей части стабильно).
Вот откуда я. У нас был поставщик, который продал нам многопользовательский продукт, который периодически, по-видимому, случайно не обновлял базу данных на центральном сервере. Мне была поручена работа нашей организации с поставщиком, чтобы решить эту проблему, так как у нас было несколько несчастных людей, пострадавших, когда это не удалось, и у наших пользователей почти нет терпения отговорок перед тем, как прибегнуть к бумажному методу отслеживания.
Производитель настаивал на том, что это приложение нормально работало в других (похожих) организациях, поэтому проблема была в нашей сети или системах. Мы заменили системы. Они настаивали на установке мини-коммутатора в соседней комнате, чтобы помочь «изолировать» трафик, потому что наш трафик был слишком высок в сети, вызывая проблемы с задержкой (хотя проблемы были только в их приложении, ничто другое не показывало явных признаков проблем с задержкой. Затем они обвинили власть, настаивая на том, чтобы мы поставили ИБП на рабочие станции и их мини-переключатель, чтобы обеспечить питание. Каждый раз случайный сбой возникал снова.
Мы прошли через все эти обручи, которые, по настоянию разработчиков, исправят, просто чтобы показать им, что НЕТ, это НЕ ПРОБЛЕМА. Проблема была довольно очевидной. Двухминутное сообщение об ошибке в Google показало, что это проблема с блокировкой файлов, а быстрое изучение их приложения показало, что оно использует базу данных MDB; в основном приложение было интерфейсом для механизма доступа. Файлы MDB в общей папке просто не предназначены для многопользовательского доступа. Когда выполнялось достаточно транзакций, в конечном итоге две из наших клиентских рабочих станций попадали в приложение базы данных в точке, где оно не могло должным образом заблокировать запись для обновления, и это приводило к ошибке.
Я не программист, я не администратор БД, это именно то, что я обнаружил при исследовании, и многие люди согласны с этим. Изменилась ли эта ситуация в более поздних версиях? Я не знаю. Но я знаю, что нашел несколько человек, которые просто сказали они делают это неправильно. «Когда у вас есть несколько клиентов в базе данных, используйте решение сетевой базы данных, предназначенное для обработки многопользовательского доступа». Бабушка может получить доступ к своим рецептам печенья. Не очень хорошо для работы с 20 пользователями, которым одновременно необходима целостность транзакций по сети.
Теперь с вашей ситуацией ... имея дело с этим поставщиком, я могу сказать, что когда поставщик настаивает на том, что клиент ошибается, несмотря на документацию в противном случае (сеть в порядке, пропускная способность в порядке, ваше приложение - единственное, что дает сбой, ошибка сама по себе указывает на недостаток в вашем дизайне ...) у них будет немного терпения, заставляя их прыгать через обручи, чтобы доказать вам, что их сеть достаточно надежна для всего но ваше приложение. Все, что в итоге делал наш продавец, это выставляло себя глупо; мы отказались от них ради конкурента после того, как утомились клоунадой с ними, и они отказались даже признать возможность того, что ошибка является ошибкой их приложения.
Мы перепрыгивали через все обручи, через которые они хотели, чтобы мы прыгнули, но все равно говорили, что это наша вина и мы были некомпетентны. Будь поставщик думает мы некомпетентны или нет, обычно неразумно говорить людям, подписывающим заказ на поставку, что они некомпетентны, не говоря уже о том, чтобы сразу отклонить свои собственные выводы о проблеме.
Далее, файловая база данных в основном полагается на другие механизмы, которые помогают защитить ее при транзакциях. Настоящий администратор БД мог бы исправить меня здесь, но в то время, как я понял, эта база данных, к которой обращались несколько клиентов по сети на сервере, имела дело с файловой системой, абстрактной файловой системой обмена файлами (совместное использование Windows) и движком это не обрабатывает надлежащую блокировку базы данных для нескольких пользователей одновременно. «Истинные» базы данных (MySQL, MSSQL, MongoDB и т. Д.) Справляются с этим лучше, потому что они созданы для этого. Доступ отлично подходит для отслеживания ваших рецептов и коллекций фильмов. Не используйте его для предприятий для обработки точек продаж или больших баз данных службы поддержки.
Почему это работает в локальной сети? Если вы скажете им (а у них есть ИТ-отдел, среди которых есть полоумный), что все базы данных должны находиться в локальной сети для правильной работы, они, вероятно, зададутся вопросом, каков ваш опыт работы с базами данных, что вы бы сделали такие заявления, если бы не знали поскольку они устанавливают свою WAN с эквивалентом модемов Hayes по линиям POTS. Истина вполне может заключаться в том, что использование файла MDB ненадежно и подвержено ошибкам; Хранение его в локальной сети снижает некоторые из ваших проблем с конкуренцией ниже порогового значения, при котором он, кажется, (обычно) работает. Если они увеличат количество клиентских приложений, использующих эту базу данных, даже в локальной сети, вы, вероятно, увеличите количество «случайных проблем», возникающих с приложением, и их ИТ-отдел будет тихо проклинать вас за то, что у вас есть дрянное приложение каждый раз. им приходится что-то перезапускать или работать с вашим приложением, если оно дает сбой.
Другими словами, сказать им, что они должны поместить его на локальный сервер, будет лишь наложить пластырь на зияющую рану. Если это конфликт файлов или проблема с движком, у них все равно будут случайные проблемы, и увеличение количества клиентов приведет к другой стене в производительности и / или уменьшит время между случайными сбоями приложения.
Не говоря уже о том, что если они реорганизовали свои общие серверные ресурсы по известным внутренним причинам, но ваш приложение должно быть специальный, что-то еще, что по какой-то причине нужно документировать или обрабатывать иначе, ваше приложение не будет одобрено ИТ-персоналом. Если вы хотите с ними хороших отношений, зачем их враждовать?
(Кроме того ... если у них есть офисы, соединяющие WAN, уверены ли вы, что удаленным пользователям никогда не понадобится использовать ваш продукт? Или они могут переместить людей, чтобы некоторые удаленные пользователи использовали ваше приложение? Тогда у вас будет разделенная сеть проблема возникает снова и снова.)
В конце концов, истинное решение - перейти на MSSQL, MySQL или какой-либо другой «настоящий» механизм базы данных, который обеспечивает надлежащий многопользовательский доступ. Это сделает ваше приложение более масштабируемым, гибким и надежным. Благодаря этому ваш продукт и вы будете выглядеть лучше.
Один из обходных путей - создать своего рода «прокси-приложение», которое сериализует запросы от клиентов, обрабатывает их, а затем отправляет ответы клиентским машинам, гарантируя, что с точки зрения базы данных все выглядит так, чтобы обрабатываться локально. Это будет препятствием для производительности и масштабирования вашего приложения, и это неуклюжий обходной путь, и, в конце концов, это совершенно неправильно решение, но если вы напишете его быстро и оно сработает, вы можете использовать его в качестве временного решения своих проблем, пока не сможете реализовать надлежащую миграцию базы данных. Если у администраторов есть упомянутая мною половина ума, они, вероятно, серьезно усомнятся в вашем опыте работы с базой данных, но они, по крайней мере, будут знать, что вы работаете над правильным путем миграции к рабочему решению.
Возможно, WAN-соединение вашего клиента ненадежно. Может быть, есть еще одна проблема, из-за которой перемещение файла базы данных в локальную сетевую систему улучшит ситуацию. Возможно, я совершенно не понимаю, как разработано ваше приложение. Но если что-то в вашем приложении похоже на ситуацию, в которой мы были, ваше приложение необходимо переработать. Если у вас есть надлежащая абстракция между базой данных и приложением, то замена движка базы данных не должна быть огромной задачей и должна принести огромную пользу. Их конкурент был основан на MS SQL Express. Без проблем. Я даже не уверен, что первоначальный поставщик, с которым у нас возникла проблема, все еще работает, несмотря на то, что у них было множество довольных клиентов, у которых не было проблем с их продуктом. Может быть, они солгали еще о чем ...
Но я действительно думаю, что вы задаете неправильный вопрос. Дело не в том, чтобы убедить клиента обойти потенциальный недостаток в дизайне приложения, а в том, как сгладить ситуацию с вашим клиентом и убедить его придерживаться вашего продукта, пока вы работаете над внедрением правильного решения для его вопросы? Это мой опыт. Это было бесплатно. Бери, как хочешь.
Вы не говорите нам характеристики производительности WAN. Я получаю доступ к большому количеству приложений через WAN, если вы имеете в виду глобальную сеть? В этом нет ничего плохого.
Если у вас есть сомнения, вам нужно будет собрать доказательства (количество раз, когда соединение WAN было отключено, сколько раз низкая производительность влияла на приложение, общее время, затраченное на выполнение действия X через LAN по сравнению с WAN и т. Д.)
Все ваши утверждения о серверах SQL выполняются по локальной сети, а не по глобальной сети, не совсем точно. Правильные серверы баз данных запускают серверные процессы на машине, которая имеет прямой доступ к хранилищу (и напрямую, я включаю SAN, iSCSI и т. Д.). Затем приложения взаимодействуют с этими серверными процессами, будь то в локальной или глобальной сети. Передача данных с диска осуществляется локально на сервере.
Я предполагаю, что вы на самом деле говорите о том, что они переместили физический файл в общий файловый ресурс, который представлен в глобальной сети, и что совместное использование файлов (SMB или что-то еще) через это соединение является медленным и ненадежным? Если это правда - соберите доказательства и покажите им, почему это работает лучше локально, но не используйте ту же аналогию, что и настоящие серверы баз данных, потому что вы вообще не реплицируете этот процесс.
Несмотря на все обсуждения, мой ответ все тот же - вы не можете сформулировать политику, вам не следует сравнивать доступ на основе файлов MDB с реальным доступом к базе данных для таких вещей, как Oracle of DB2, и лучше всего собрать реальные вещественные доказательства и представить который.