MS Access как корпоративное программное обеспечение?

Ответ 1

Я много работал с этим сценарием. Фактически в качестве консультанта/разработчика Access Front end конец SQL Server был важной частью моей работы с хлебом и маслом за последние 10 лет. Это не значит, что мне нравится Access; -)

До общего принятия AJAX это было вполне разумное решение. И все еще существует огромное количество приложений малого и среднего размера, собранных в Access Access, которые успешно работают на заказных бизнес-системах, и я сомневаюсь, что он уйдет в течение следующих 10 или более лет - действительно, Access/SQL, вероятно, будет Коболь XXI века. Если вы работаете на сайте "зеленого поля", то теперь практически нет оправдания для развертывания Access при создании с нуля - но если вы наследуете существующее приложение, тогда затраты на переписывание могут оказаться неосуществимыми и трудными для прохождения пользователей.

Доступ имеет некоторые преимущества, которые по-прежнему значительны - и может представлять проблемы, если вы предлагаете преобразовать в веб-приложение

• Это быстро. Для простой работы CRUD это так же быстро записывается и развертывается, как и любое другое реалистичное решение.
• Встроенная отчетность легко запускается и замечательно мощна при использовании системы. Обычно довольно легко создавать и развертывать новые отчеты для пользователей по запросу.
• Он хорошо интегрируется с Office. Это, как правило, шоу-стоппер, когда вы хотите переместить приложения Access в веб-приложения. Это чрезвычайно распространено для приложения Access для размера раздела тесно с Outlook, Word или Excel - и часто все три. Это серьезная проблема при работе с реальными ситуациями. Очень просто для кодировщиков недооценивать важность этого для повседневного использования таких систем, и наложение даже небольшой степени дополнительной хлопот для пользователей, как правило, будет сопровождаться большим сопротивлением - достаточно часто, чтобы полностью разрушить проект.
• Если вы работаете с отделом разумного размера - дюжина человек или около того - довольно часто для того, чтобы быть кем-то в офисе, который воображает себя как компьютерный мастер. Эти люди могут стать серьезной болью при неправильном обращении, но в равной степени могут быть основным активом. Если у меня есть такой человек, я попытаюсь заставить руководство отправить их на курс доступа или два, чтобы они могли писать простые запросы и отчеты и настраивать отдельное приложение Access для них, которое у них есть, у которого есть соответствующий (ограниченный) доступ к базы данных SQL. Затем вы можете доверять этому человеку, чтобы он обрабатывал простые отчеты и тому подобное для своих коллег. Это может быть настоящим беспроигрышным - вы получаете кого-то, кто на вашей стороне, и будете использовать вас в качестве наставника - готового адвоката для вас в отделе - и они сохраняют отчет о ворчании из ваших волос. Они получают много удовольствия и удовлетворенности работой - и даже потенциальный карьерный путь. Это гораздо сложнее, что почти невозможно, делать такие вещи с любой другой системой, кроме Access.

Основные практические недостатки

• Развертывание может быть кошмаром. Как правило, если у вас очень плотная среда - небольшая компания, один отдел, основанный на Citrix или распределенный с ИТ-отделом, который тщательно контролирует его ПК, тогда вы в порядке. Развертывание как коммерческое приложение для нескольких компаний - хорошо, только если вы можете взимать значительное обслуживание (были там).
• Код не масштабируется. Доступ к коду VBA, даже если он написан профессионалом, имеет сильную тенденцию гнить в прогорклые спагетти. Это довольно распространено, чтобы в итоге получить приложение Access, которое было достаточно легко поддерживать, но постепенно становится недостижимым по мере умножения зависимостей.

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

Ответ 2

Мы создали такое решение (клиентский интерфейс Access, серверный SQL), в котором сейчас около 80 пользователей, миллионы строк реплицируются между разными странами, более 100 000 обновлений в месяц. Работает нормально. Я думаю, что главная ошибка в Access - это рассматривать его как инструмент, созданный для любителей разработки приложений. Это может работать таким образом, но имейте в виду, что любительская разработка даст вам любительские приложения, в то время как профессиональная разработка даст вам профессиональные результаты.

Краткий список его преимуществ, проблем и ограничений:

• Это бесплатно для конечного пользователя, благодаря среде выполнения msAccess
• Он работает с бесплатным SQLServer Express и не очень дорогим SQL Server Enterprise.
• Это быстро, особенно при работе с формами
• Он очень легко связывается с другими приложениями Office, которые по-прежнему являются корпоративными стандартами.
• Вы можете управлять его интерфейсом так, чтобы он был настолько близок к стандартам Office, что его использование могло быть очень интуитивно понятным, делая людей счастливыми (я немного рассказал об этом в своем блоге, нужно обновить!)
• В больших масштабах вы должны подумать о том, как лучше всего распространять его среди своих пользователей. Как отмечает #Cruachan, эта проблема может превратиться в кошмар, но ее можно решить, например, путем создания и распространения пакетов msi. Такие msi-пакеты также могут содержать все ваши внешние ссылки, такие как "добавленные" dll, ocx, tlb файлы (отчет dll, элементы управления сканера ActiveX и т.д.). У нас было несколько слов по этому поводу здесь.
• При распространении обновленной версии файла mdb у вас может быть общая сетевая папка, содержащая новый файл mdb/zipped, который клиенты будут проверять/обновлять при запуске. Ваши клиенты должны иметь возможность переустановить предыдущую версию файла MDB. Обновление становится легче, чем установка нового .exe файла.
• Вы должны установить систему контроля версий. Пожалуйста, проверьте здесь для деталей.
• Вы должны быть очень строгими в своей организации кода. Одним из наших основных правил является, например, не иметь никакого специального кода на уровне формы. Пожалуйста, проверьте здесь на эту тему.
• Я не обнаружил никаких проблем с масштабированием кода VBA, как заметил #Cruachan. Если будут реализованы профессиональные правила кодирования, не будет никаких необычных проблем с масштабированием кода. Например, наше приложение теперь работает очень хорошо с более чем 180 различными формами и продолжает расти без каких-либо проблем.

В заключение, наша главная проблема с Access - это проблема с имиджем, когда Microsoft все еще позволяет людям думать, что Access здесь, чтобы дать им возможность разработать настоящее программное обеспечение за 10 уроков... и профессионалы, которые знают, что это невозможно, просматривают это как любительский инструмент для любительской разработки, который смотрит на пользователей с ms-access как на скучную шутку с низким IQ.

Ответ 3

Я знаю немало профессиональных разработчиков Access, которые разработали и поддерживали приложения уровня предприятия, используя Access как front-end (MDB или ADP) и поддерживая группы пользователей в 100-х годах (и даже в нескольких случаях - тысячи).

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

Как ни странно, принципы проектирования, которые делают для эффективного приложения уровня предприятия, также обеспечивают более эффективное приложение Access на уровне рабочей группы.

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

Да, это трудно сделать правильно.

Но на этом уровне, так же как и любая другая платформа разработки, все они требуют планирования, опыта и высокоуровневого набора навыков.

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

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

Ответ 4

Я начал делать настольные приложения в Access с JET-серверами. Я перешел к использованию SQL Server/MSDE с Access как front-end, а затем VB6 и небольшим классическим ASP.

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

Тем не менее, я думаю, что есть сценарии, где он все еще работает, чтобы использовать Access. По моему собственному опыту, я вернулся к Access с базой данных SQL, когда мне было дано задание разработать корпоративное решение, хотя и для гораздо меньшего предприятия, за очень короткий промежуток времени. Главной причиной моего решения было время. Я могу собрать пользовательский интерфейс базы данных в Access намного быстрее, чем я могу в любом другом инструменте. Некоторые из них знакомы с инструментом, но многое из этого заключается в том, что Access просто дает вам больше бит для конкретной базы данных, чтобы работать с ним. Интерфейс доступа можно также настроить, чтобы выглядеть и работать очень похоже на стандартное приложение WinForms.

Захват, с которым многие сталкиваются в корпоративном сценарии, - это перемещение Access и приложения MDB/MDE в массы. Это легко решить, настроив его на сервере терминалов Windows, который также может быть сфальсифицирован, чтобы работать почти как другое окно приложения на клиентской машине с правильными параметрами файла RDP. Но даже этот подход имеет свои пределы. Я не думаю, что он будет масштабироваться в тысячи очень хорошо, но для нескольких десятков пользователей я обнаружил, что он работал отлично, и купил достаточно времени, чтобы удовлетворить временные ограничения, с которыми мне приходилось работать, поэтому веб-интерфейс может быть реализован, когда время допускается.

Для профессионала, который знает, что они делают в базе данных SQL, передняя часть Access не обязательно является непростительным грехом, особенно когда мандат дешев и быстр, и нет религиозного пуризма.

Ответ 5

Для большого количества CRUD (Create Read Update Delete) работа MS Access в порядке. Я уверен в этом, если данные находятся в другом движке (MSSQL/Oracle/MySQL). Однако большую часть времени у меня проблемы с базой данных MS Access, потому что:

• Это был домашний домашний пользователь (не программист/ИТ-специалист) и не планировал вперед для будущего развития (так что добавление часто становится более болезненным, если участие в проекте было)
• Он заполнен ненормализованными таблицами, непостоянствами и таблицами без ключа.

Мое решение. Ограничьте доступ MS к профи и разверните версию среды выполнения на настольные компьютеры пользователей.

Ответ 6

Для многопользовательской ситуации с большим объемом данных я использую интерфейсы Access с задней частью MySQL. Я должен сказать, что в ситуации клиент-сервер, особенно в локальной сети, MS Access так же хорош, как и они. Лично я нахожу разработку в MS Access намного быстрее, чем говорят Visual Studio, особенно когда речь заходит о приложениях, управляемых базой данных. Отчеты Access также хороши, если не лучше, чем отраслевые стандарты Crystal Reports. Единственный недостаток, который я вижу в Access, - это когда дело доходит до ситуаций, не связанных с локальной сетью, когда вы должны распространять приложение для пользователей, охватывающих широкий географический район. Но опять же, у самих веб-приложений есть большой недостаток - обработка отношений "один ко многим", что-то доступное превосходно обрабатывает с помощью своей суб-формы, функции суб-отчета. И что еще более важно, Access имеет очень мощную модель событий, с которой большинство приложений не могут сравниться. Лично я могу буквально сделать что угодно на Access! Итак, мой вывод заключается в том, что MS Access обладает многими преимуществами, которые делают его компетентным инструментом разработки, особенно в средах локальной сети.

Ответ 7

Если у вас есть выбор, нет.
При этом есть ситуации, когда это может быть хорошо. Одна из ситуаций заключается в том, что вы никогда не планируете обновлять приложение доступа. Если он установлен для тысяч пользователей, у вас могут возникнуть проблемы с обновлением всех клиентских приложений.
Вам намного лучше сделать веб-интерфейс... Несмотря на то, что Access облегчает создание нескольких форм-макетов, чем что-либо, что я видел. Даже Oracle Application Express, предназначенный для конкуренции с Access, не может делать все, что делает Access.
Мой совет: если вы программист, вы можете сделать приложение asp.net, которое будет выполнять ту же работу в гораздо более масштабируемой, поддерживаемой природе.

Ответ 8

К сожалению, у меня довольно много опыта с этим. Мы создали целый продукт для привязки Access Forms к базе данных SQL. Честно говоря, производительность не была проблемой - на самом деле это обычные сценарии типа соединения db, которые вам нужно беспокоиться с любым клиентским/серверным приложением. В нашем случае оригинальный разработчик знал тонны "трюков" в Access и делал такие вещи, как сброс данных привязки к хранимым процедурам. О, и ужасные триггеры. Ужасно. Как и в, 45 триггеров стреляют за обновление ужасно.

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

Итак, я бы не сказал, что это вполне приемлемое, стабильное, поддерживаемое или надежное решение. Это сработало для нас, потому что мы были там, чтобы поддержать его (и в конечном итоге переписать его в .NET), но я бы не рекомендовал его для всех. Тем не менее, я работал в правительстве, где попытки получить что-либо от "ИТ" (в котором я участвовал) были настолько заполнены бюрократией и документами, что отделы часто использовали решения Access.

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

Ответ 9

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

Когда вы говорите "Доступ как решение", то, что приходит мне на ум, - это простое настольное приложение 2-3, которое собирает сотрудник по маркетингу, а не настоящий разработчик. Если у маркетолога была действительно хорошая идея, то, возможно, разработчик должен посмотреть на него (я предполагаю, что есть один смысл, который вы указали, могут быть тысячи пользователей), реорганизовать его на лучшую платформу (интранет или winforms, распространяемые через ClickOnce, и т.д.), а затем разверните его.

Еще в начале 90-х я был разработчиком Access, даже имея сертификацию MS. Я построил десятки приложений "Enterprise" (это означало, что их использовали 10-15 человек). Те дни ушли, ИМО. Есть более простые решения для сборки, развертывания и обслуживания в настоящее время.

Ответ 10

У меня было несчастье работать над концами Access, как вы описали, вот некоторые аргументы не-Enterpise.

Программирование просто! Создание форм в доступе ориентировано на не-разработчиков. Например, если у вас несколько столбцов в раскрывающемся списке, у вас есть поля списка и поля данных. Ни за что! вы просто устанавливаете его ширину вещей, которые вы не хотите видеть до 0 ". Таким образом, вы смотрите на формы, сбрасываемые вместе не-разработчиками, или это будет раздражать большинство людей, которые должны работать на них.

Versioning? Кому нужно управлять версиями?, Просто отправьте вложение. Если изменения должны быть сделаны для внешнего развертывания, это требует много времени и подверженности ошибкам.

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

Ответ 11

Когда Microsoft выпускает бесплатные версии (MSDE или SQL Express для 2005 года) с движком SQL Server с каждой версией, нет необходимости использовать Access больше. Несмотря на то, что эти бесплатные версии не имеют визуального интерфейса, который может сделать процесс разработки более сложным, хорошее знание SQL - это все, что вам нужно.