Чем access лучше 1с
Существует большая-большая база на MS Access, можно сказать целое предприятие работает в ней. SQl не используется, пользователи сидят на серваке в ней по RDP.
Необходимо собрать не менее 10 аргументированных причин ухода от MS Access
Оценить 5 комментариев
Какие могут быть аргументы при абстрактном вопросе?
Работает - не трогай. Вот уже один аргумент "против" (если что - сам не пользуюсь, ибо это офисный продукт и под винду, а винды нет и не надо, как и офиса тоже как такового).
AVKor: Какие могут быть аргументы при абстрактном вопросе?Сергей нашел 7 аргументов при абстрактном вопросе например.Аргументированно - это когда известно, какая именно задача решается, какие именно требования к инструменту и т.д. При определённых обстоятельствах можно представить гипотетически условия, при которых каждый из этих 7 не будет иметь значения.
Это я не к тому, что мне нравится access (это, вообще-то, дерьмо, а не СУБД), но при решении вопросов такого рода всегда надо исходить из конкретики, а не исследовать сферического коня в вакууме.
AVKor: Ну вот видишь, ты просто назвал его дерьмом, а суть моего вопроса: "Почему ты думаешь что он дерьмо? Можешь рассказать мне?" Ну как там ваша большая БД поживает?Удалось переехать на СУБД промышленного масштаба?
Access это
1. Устаревшее решение. Все сложнее найти специалиста, который бы мог порешать проблемы в случае чего, и чем дальше откладывать переход, тем болезненнее он может оказаться впоследствии.
2. Access не многопоточный. несколько пользователей могут мешать друг другу.
3. Access не очень надежный в плане отказоустойчивости - один (в лучшем случае несколько связных файлов), но это работа на уровне файловой системы. Отсутствие онлайн-бэкапов, неудобная структура для их создания. При большой базе возможны проблемы. Практически невозможно делать инкрементальные бэкапы.
4. Access платный. Работать нормально он может только на платной же Windows платформе.
5. Реализация многих вещей в Access редко когда позволяет легко перейти на новую версию того же Access-а, что может помешать его работоспособности даже в пределах текущей платформы.
6. Нет удобных штатных способов создавать онлайн-формы. Через IIS это опять таки платное решение с кучей гемора.
7. RDP сам по себе не самое хорошее решение просто для того, чтобы вводить данные в базу. Даже с небольшим увеличением пользователей, нагрузка на сервер повышается очень сильно даже при простое. В то время как веб-sql решение, может быть даже незаметно для пользователей, количество которых увеличилось на порядок.
Чем хорош access:
1. В первую очередь, это комбайн. Все свое, все на месте - формы, таблицы, программный код, стандарты. Не нужно ничего другого.
2. Приложение уже написано, работает, знакомо.
Переходить нужно, если на это есть средства (на саму миграцию) и если есть некие опасения, что access не устроит в будущем. Если же расширения фирмы не планируется вообще, то тут надо пояснить бизнес-выгоду.
Если вы используете лицензионный софт, то с этой точки зрения вполне можно найти выгоду, отказавшись от rdp, виндовс сервера и офиса с access, заменив это все на бесплатный linux сервер + apache/nging и реализовав логику на php/python/java/perl (что душе угодно) и бесплатную базу данных (mysql, oracle 1
Спасибо что поняли суть.
И спасибо за хороший ответ, всё актуально кроме пункта 6. Было бы замечательно подкинуть ещё пару пунктов.
С точки зрения лицензионного софта выгодны не получить, т.к. всё уже куплено и это ни куда не деть) Вот если бы изначально всё сделать нормально. Столько экономии на одних лицензиях на подключения к серверу. Но это уже совсем другая история.
KJIayD: Подкинуть еще пару пунктов сложно. Но вы расширьте пункт 1.
Если переписать решение на современных языках, очень легко можно будет расширить функционал. Найти любого специалиста, и не боясь что-либо ломать, внедрять множество нового функционала, парралельно работе, обеспечив прозрачный доступ и прозрачное разграничение доступа для разных пользователей.
Для расширения функционала, всех нужно выгонять, парралельно тестировать и работать нельзя.
При переводе в sql, парралельные запросы легки, быстры, отлично масштабируются.
А, вот еще пункт.
Я не помню есть ли в access вообще ограничение доступа, кроме как через формы (когда юзер не знает как напрямую залезть в таблицу). В SQL легко ограничить доступ разных пользователей к базе, логирование и мониторинг кто именно что делал делается за минуты.
Какие можно выделить преимущества 1С над Access?
В БД сейчас у него работает 3 юзера, в дальнейшем будет 5, в дальнейшем он хочет заходить из дома в БД удаленно. А потом потом хочет объединить местный офис с рижским.
Как человека уговорить? Помогите!
(0) если уже всё работает, то зачем юзеру "платить больше"?
яхты это лакшари, а 1С намного гламурней Access, круче 1С только SAP(7) Читаем (0) "В БД сейчас у него работает 3 юзера, в дальнейшем будет 5"
Т.е. клиент доволен.. У него всё работает.. Так?
(0) Если ты сам, общаясь непосредственно с клиентом, не в состоянии сформулировать что конкретно тот получит от внедрения 1С, то что ты ждешь от мистян? Очередного сеанса группового телепатирования и чтения мыслей твоего клиента на расстоянии?
(0). хочет, чтобы я покритиковал Access - программы на Access пишут студенты
а на 1С - настоящие бизнес-аналитики
(11) Он не доволен. Не доволен функционалом, интерфейсом. Да и его друг программист исчез. И тут появился я. Такой растакой. Но в ацессе кодить не умею. Предложил ему 1С
(16) вот за это и цепляйся - программистов 1С легион и они постоянно будут развивать его решение.
Можно ли сделать удаленный доступ в файловом варианте 1С?
Скажи ему, что все его конкуренты уже давно на 1с работают :)
(16) Это всё лирика. Пусть сам сформулирует что конкретно он хочет получить от своей программы. Причем сформулирует это безотносительно платформы, на которой его хотелки будут реализовываться. Только после этого можно будет сказать на чем лучше и может быть дешевле это сделать.
А без этого всё здесь сказанное будет лишь обсуждением, кто сильней - слон или кит.
(25)
1. Какая скорость инета должна быть чтобы люди работали в БД локально (3-5 человек) и удаленно (5-7)
2. Отчеты будут выполняться также быстро?
3. Файловый вариант точно потянет? Зачем тогда нужен клиент-серверный вариант
(26) с таким отвратительным знанием предмета вы впариваете (по другому не скажешь) клиенту 1С?
У меня нет слов.
(26) Очередные вопросы "ни о чём". Говорить о производительности системы можно только зная о ней хоть что-нибудь. Например, какая конфигурация (типовая или самописка), если типовая, то какая именно (УТ и УПП весьма разнятся по производительности), какой объем информации (ежедневный объем документооброта, размеры основных аналитических таблиц типа Номенклатуры, Контрагенты или что там у него будет). Вторым вопросом встает производительность железа, на котором это всё будет жить.
Короче разговор о сферических конях.
(26) >> Зачем тогда нужен клиент-серверный вариант
Он не нужен. Его 1С придумала, чтобы бабло стричь с доверчивых лохов.
По определению Аксесс - персональная БД, что означает ее полную неспособность поддерживать многопользовательский доступ. Правило здесь такое: если Вы пишете приложение для нескольких concurrent (извините, я не знаю, как это будет по-русски) соединений, то лучше использовать Сиквел. Сейчас есть его бесплатная версия Экспресс, а скоро появится 12-я версия с "локальной БД". Если Вы предполагаете, что объем базы будет больше 2Гб, то Аксесс и в этом случае надо исключить из кандидатов. Аксесс также медленней, чем SQL Сервер в любом варианте.
Главное преимущество SQL баз перед Аксессом не только мультисоединения, но и факт, что Вам не придется ничего переписывать, если потребуется перейти на полный SQL сервак.
Тем не менее, не надо слушать неверные советы: если Вам все равно, какой будет движок, лишь бы обеспечивал "непрямой" доступ (ODBC connections), то Аксесс вполне сгодится, т. к. вполне поддерживается ADO.
Это координально разные вещи. Ацесс имеет смысл применять для маленьких баз потому как там используется прямой доступ к базе. sql для больших баз (жто очень гркбое определение, для точности описания места здесь не хватит)
Спасибо)Я просто когда делала базу, особых отличий не увидела
Владимир Оракул (56967) Разница ощутима на базе размером начиная с 500 мб. К тому же сервер sql поддерживает такие функции как встроенные процедуры которые работают не на уровне прикладного по а на уровне самой базы.
Для мелких проектов-в-себе, с интерфейсом и базой в одном файле, при ограниченных ресурсах и при отсутствии необходимости совместного использования данных, лучше Access. В остальных случаях лучше нормальные RDBMS, необязательно MS SQL (и даже лучше бы без него).
По большому счету, Access вообще не надо употреблять ни для каких баз.
Слишком кривой пакет, Микрософту он явно не удался, хотя понты кидает большие, входит только в Профессиональную версию Офиса.
Access - платное, убогое, виндозное поделие, MS SQL не такое убогое, но остальные недостатки те же. Если для проекта подходит даже Access, то лучше использовать, например, SQLite.
Аксесс для работа одного пользователя, на локальной машине и количество записей не может привышать 65536.
скл-сервер для работы до 2 тысяч пользователей, и количество запсей таблицы поболее
Заметил, что когда спрашиваешь кого-нибудь, особенно на собеседовании, какие типы СУБД существуют, то первое что вспоминают многие – это реляционные базы данных, и NoSQL, а вот про разновидности часто забывают или не могут сформулировать их отличие. Поэтому начнем с простого перечисления наиболее используемых.
Тем, кому не хочется долго читать, может сразу перейти на итоговую таблицу .
Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.
Реляционные СУБД
Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.
Наиболее известные СУБД такого типа - Oracle, Microsoft SQL, PostgreSQL, MySQL.
Когда выбирать реляционную СУБД
Один из основных признаков, который говорит о том что нужно выбирать реляционную СУБД – это высокая нормализация данных. Дополнительными признаками будет необходимость обработки большого кол-ва коротких транзакций, с большей долей операций на вставку
Когда не выбирать реляционную СУБД
Если предполагается хранить не структурируемые данные, или наоборот очень простые структуры типа ключ-значение, то лучше посмотреть в сторону документных СУБД и специализированных СУБД типа ключ-значение соответственно.
Так же один из признаков, что имеет смысл подумать не о реляционных СУБД, это такой факт как необходимость часто обновлять значения в одних и тех же строках. Обычно это обходится "дорого" в реляционных СУБД, и нужно применять "продвинутую магию" что бы делать это корректно.
Конечно, тут есть много «но», или «а если очень хочется», и других ситуаций, когда данные рекомендации можно игнорировать. Это нормально, особенно когда за дело берется эксперт, который знает как это сделать.
СУБД типа ключ-значение
Наверное один из самых простых типов СУБД. В упрощенном виде, это некая таблица с уникальным ключом и собственно связанным с ним значением, в котором может быть что угодно. Чаще всего такие СУБД используют для кэширования, т.к. они очень быстро работают, а это и не сложно, когда есть уникальный ключ, и запрос возвращает только одно значение. У некоторых представителей данных СУБД есть возможность работать полностью в памяти, а так же есть возможность задавать срок жизни записи, после истечения которого, записи будут автоматически удаляться.
Наиболее известные СУБД такого типа - Redis и Memcached.
Когда выбирать СУБД ключ-значение
Когда не выбирать СУБД ключ-значение
Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.
Документные СУБД
Документные или документно-ориентированные СУБД - это одна из наиболее популярных разновидностей NoSQL СУБД, где основной единицей логической модели данных является документ - структурированный текст, с определенным синтаксисом.
Иногда встречаются мнения что модель данных в документных БД похожа на модель данных в объектно-ориентированных базах данных. В этом есть доля правды, единственная реальная разница между ними заключается в том, что базы данных документов только сохраняют состояние, но не поведение.
Так же, само название "документо-ориентированная" подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.
Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.
Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.
Когда выбирать документную СУБД
Если нужно хранить объекты в одной сущности, но с разной структурой. Если нужно хранит структуры, включая объекты, списки и словари, особенно в формате близкому к JSON.
На самом деле область применения документных СУБД очень широкая. Их можно использовать как компактную базу данных для отдельно взятого микро-сервиса, так и для вполне масштабных решений, в качестве хранилища состояний чего-либо.
Когда не выбирать документную СУБД
Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.
Графовые СУБД
Графовые СУБД - специфичный тип, предназначены для работы с графами, с их узлами, свойствами, и произвольными отношениями между узлами.
Очень простой пример, это организация связей в различного типа социальных сетях, где нужно хранить связи между пользователями (узлами) по разным критериям (родственные связи, коллеги, общие интересы).
Известные представители этого типа субд - Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.
Когда выбирать графовые СУБД
Точно стоит обратить внимание на графовые СУБД, если строите какое-то подобие социальной сети, или реализуете систему оценок и рекомендаций. Ну и во всех случаях когда вы хорошо понимаете что такое графы, и для чего это нужно.
Когда не выбирать графовые СУБД
Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.
Колоночные СУБД
Колоночные СУБД очень похожи на реляционные. Они так же состоят из строк, которые имеют атрибуты, а строки группируются в таблицах. Различия в логических моделях несущественные, а вот на уровне физического хранения данных различия значительные.
В реляционных СУБД данные хранятся "построчно", это означает что для считывания значения определенной колонки, придется прочитать практически всю строку, как минимум от первой до нужной колонки. В колоночной СУБД данные хранятся "поколоночно", т.е. колонка - это как отдельная таблица. Соответственно чтение будет происходить из конкретного столбца сразу. На практике это реально работает очень быстро (проверено мной на нескольких реализованных хранилищах данных).
Основные преимущества колоночных СУБД – эффективное выполнения сложных аналитических запросов на больших объемах, и легкое, практически мгновенное, изменение структуры таблиц с данными, плюс существенная компрессия и сжатие, которое позволяет значительно экономить место.
Яркие представители колоночных СУБД - Sybase IQ (ныне SAP IQ), Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra.
Когда выбирать колоночные СУБД
Один из весомых аргументов за использование именно колоночной СУБД - это если вы хотите построить хранилище данных, и планируете делать выборки со сложными аналитическими вычислениями. Косвенный признак, который так же может сигнализировать о том, что имеет смысл, хотя бы посмотреть в сторону колоночных СУБД - это если количество строк, из которых делаются выборки, превышает сотни миллионов.
Когда не выбирать колоночные СУБД
Учитывая специфику колоночных СУБД, будет не эффективно ее использовать, если выборки достаточно простые, параметры выборки статичны, и если преобладают выборки по ключевым значениям. Так же, если количество строк в таблице, из которой делается выборка, меньше сотен миллионов строк, то скорее всего не будет большого преимущества, по сравнению с реляционной СУБД.
Нужно так же иметь ввиду, что в колоночных СУБД могут быть и другие ограничения. Например, может отсутствовать поддержка транзакций, а язык запросов может отличаться от классического SQL, и прочее.
Итоги
Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.
При выборе типа СУБД следует, прежде всего, исходить из типа решаемых задач, типов обрабатываемых данных, перспектив роста и масштабирования.
Обращайте так же внимание на популярность и наличие широкого круга разработчиков и средств разработки – это даст вам возможность, при необходимости, найти ответ на возникший вопрос быстро.
В данной статье я намеренно не делаю акцент на выбор между облачными и on-premise решениями - эта тема одной из следующих статей.
Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.
Тип СУБД
Когда выбирать
Примеры популярных СУБД
Нужна транзакционность; высокая нормализация; большая доля операций на вставку
Oracle, MySQL, Microsoft SQL Server, PostgreSQL
Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON
CouchDB, MongoDB, Amazon DocumentDB
Задачи подобные социальным сетям; системы оценок и рекомендаций
Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid
Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов
Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra
Надеюсь данная статья оказалась полезной.
В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.
Читайте также: