Джентльменский набор разработчика Access

[@serkuzm]

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

[@toxicdream]

Ограничение в 2 гигабайта в свое время попортило мне много крови и нервов.
В общем, по возможности, старайтесь MS Access не использовать.
Его уже очень давно не развивают — оставили для совместимости и демонстративно-обучающих целей.
Майкрософту еще один конкурент их же MS SQL-ю совсем не нужен.

[@asommer]

Да, это что-то вроде лайт версии базы данных. Самое то для обучающий целей. В случае необходимости можно подцепить табличку из какой-либо базы ( из того же SQL Server-а ). А, еще удобнее, чем в Excel хранить какую-то базу данных ( например телефонов ).
Так как язык Visual Basic довольно простой, то может использоваться более-менее продвинутым IT руководством в своих целях.
Для каких-то серьезных многопользовательских проектов действительно лучше ни-ни…
Я думаю Access переродится во что-то новое вроде Sharepoint или SQL Server Compact…

[@Isopropil]

А не дофига ли баблища хотят за примитивную записную книжечку для телефонов? ИМХО — есть более адекватные записные книжечки, может быть — даже облачные. А для целей обучения — вы ещё фокспро или клиппер предложите. Может быть, обучать стоит на чём-то более нормальном?

[@Isopropil]

Кто-то ЭТО всё ещё использует для чего-то, кроме дремучего легаси?

[@DSB75]

У Access есть своя ниша и она не сказать что маленькая. Безусловно, это довольно мелкие приложения уровня отдела предприятия. Часто это промежуточный костыль между ERP и конечными пользователями.

[@Isopropil]

Хреновая ERP, если к ней костыли нужны. Тем более — такие.

[@DSB75]

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

[@Kozy]

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

[@McKinseyBA]

Не очень понятна сложность расчетов для которых Вы ищете альтернативу, но ограничение Excel в 1 млн строк легко снимается при помощи бесплатного add-in MS PowerPivot. А DAX, собственный язык PowerPivot, весьма функционален и шустр.

Если честно, после появления PowerPivot я почти забыл про существование Access, хотя примеров использования именно как

мелкие приложения уровня отдела предприятия. Часто это промежуточный костыль между ERP и конечными пользователями.

привести могу, в том числе и в компаниях из списка Fortune Global 500 в связке с SAP например.

[@Kozy]

У меня, например, задача по сути сводится к расчету суммы f(n) по n от 1 до totaln, где totaln может быть достаточно большим. При этом f() — сложная функция, которая довольно долго работает, и нет возможности ускорить путём добавления промежуточных результатов в новые «столбцы» — время обновления сравнимо с временем расчета.
Был огромный макрос в экселе, который все это считает, переход на access дал увеличение скорости в десятки раз.

За PowerPivot спасибо — изучу. Но боюсь, все равно будет медленнее access — ну не заточен excel под такие объёмы.

[@DSB75]

Ограничение 20^2 строк в Excel сугубо теоретическое. Пользоваться Excel файлом уже после 100-200 тысяч строк проблематично, а уж с расчётами вообще — туши свет. Access как раз тут и вступает в свои права. SQL — это уже другой уровень и по инфраструктуре, и по деньгам, и по уровню навыков.

[@McKinseyBA]

Видимо, я избалован SQL-серваками, но даже задачу уровня описанной ниже решал бы при помощи denvera. Если предложите решение в Access за 30 мин — с меня Вам плюс))

[@DSB75]

Я думаю, что указанную задачу надо было решать при помощи одной единственной формулы в Excel :)

[@McKinseyBA]

Либо я невнятно описал проблему, либо Вы невнимательно прочитали условие задачи :-)

Нужно вычислить не 1, а много медиан — специально указал на медиану в сводной таблице. Стандартной формулой не решить, хотя на excelplanet пытались, но у меня не взлетело — много если.

PS: думаю в условии следовало использовать «медиан» вместо «медианы» — тогда было бы яснее

[@DSB75]

В любом случае, в Excel это решать сподручнее, чем на Access.

[@McKinseyBA]

Так и думал, что «плюс» останется у меня)))

[@DSB75]

А вам показалось, что он мне был нужен? Напрасно.

[@McKinseyBA]

Извините, если обидел. Но, на конкретный пример из Вашего выражения

Пользоваться Excel файлом уже после 100-200 тысяч строк проблематично, а уж с расчётами вообще — туши свет. Access как раз тут и вступает в свои права.

Вы сами и ответили чуть выше.

ИМХО: лично мне очевидно постепенное сокращение зоны потенциального применения MS Access, как снизу, благодаря развитию возможностей MS Power, так и сверху, благодаря упрощению разворачивания полноценных SQL-серверов. Не удивлюсь, если через несколько лет MS Access в нынешнем виде может исчезнуть из продуктовой линейки. Время покажет…

[@McKinseyBA]

Кстати, глянул количество статей на Хабре с тегом Microsoft Access: 3 статьи, с 13 "+" на троих и менее чем 25000 просмотрами на всех…

Неужели тема настолько непопулярна?

[@DSB75]

Послушайте, я даже не думал ни спорить, ни тем более обижаться :)
Абсолютно согласен, что времена настольных СУБД уходят. Действительно, Power надстройки Excel отвоёвывают нишу Access, а SQL продукты становятся достаточно привычными. Тот же MS SQL Express денег не просит (в отличие от Access), а обладает неоспоримыми преимуществами. Но лет 10 Access ещё точно протянет до момента изгнания из состава офисного пакета. Много старых приложений; SQL усложняется и пользователи его боятся; высок барьер знаний, чтобы начать им пользоваться; Excel слишком обременён своей архитектурой, чтобы хотя бы приблизиться к Access в плане производительности. Есть ещё ниша у Access, есть. Опять же Access позиционируется в качестве Front-End-а для SQL БД. В общем, это неплохой вариант для разработчиков низкой и средней квалификации. И он ещё долго им останется.

[@McKinseyBA]

Не очень понял за что минусов наставили, я вот лично согласен с последней фразой (ну, кроме оценки времени). DSB75 — достойно дискутировал.

[@DSB75]

Да не обращайте внимания, я понял, что это не вы.

[@McKinseyBA]

Видимо обострилось чувство справедливости в начале четвертого десятка))

Согласен когда по делу, а просто так… не понимаю.

PS: интересно, сам нарвусь на минусы?)

[@McKinseyBA]

Мдам, тогда согласен. У меня потолком сложности вычислений был одноразовый поиск медианы для массива данных в 100K строчек (в сводной таблице). При этом под рукой был мускульный сервак большой производительности, но силами SQL, без создания промежуточных таблиц не смог решить проблему — были только права на SELECT. Зато за 20 минут гуглинга нашел на просторах интернета .xla расширение с отличным кодом VBA внутри, решившим проблему за 10 сек раздумий.

[@nzeemin]

Базы MS Access когда-то было очень удобно использовать в качестве «лёгкого» решения для того чтобы использовать одну базу несколькими пользователями — база шарилась через виндовую шару и работаем с нескольких клиентов через драйвер Jet.
Но сейчас с этим работать я бы уже не стал — лучше обновить до полноценного SQL Server.

[@Goodkat]

А как пользователю работать с SQL Server? Вручную запросы на SQL писать? Теребить программистов, чтобы сделали ещё одно приложение для очередного отчёта, который, быть может, никогда больше не понадобится? А в Access он сам за 15 минут склепал пару формуляров и таблиц и доволен.

[@art_karetnikov]

Для акцесса есть очень хорошая и удобная библиотека SQLhelper. Лежать она должна, по идее, по всему интернету, а скорость разработки с ней увеличивается очень значительно — особенно для тех, кто не пишет запросы руками. Основное ее предназначение — улучшить взаимодействие акцесса и ms sql. И вот такая обвязка работает просто чудесно, пишется быстрей, чем на дельфи, например.
Незаслуженно акцесс забывают, есть у него добрые фишки.