Не является ли SQLite немного недооцененным? [закрыто]

Прежде чем я задам вопрос, позвольте мне сначала описать мои мысли о SQLite.

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

Например: MS-SQL может обладать гораздо большей функциональностью, масштабируемостью и т. Д. И т. Д., Но его также может быть сложно установить, если вам не повезло. Конечно, я не говорю, что сложная установка - причина не выбирать конкретную базу данных.

Не поймите меня неправильно: MS-SQL - продукт хорошего качества. Я очень опытный с MS-SQL; Я очень хорошо понимаю продукт как профессионал. Я просто предпочитаю это меньше в некоторых случаях, когда это действительно не нужно (= не много пользователей, <10-15).

Какую функциональность базы данных вы действительно используете? По моему опыту это часто просто обычный SQL (SELECT, INSERT и UPDATE).

Мне нравится SQLite. Захватывающе быстро. Это очень легко "установить". Я думаю, что SQLite может сделать больше, чем утверждает, что может. Зачем использовать его только для однопроцессных / однопользовательских приложений? В конце концов: не многие приложения постоянно обращаются к базе данных.

Например: рассмотрим приложение ERP, скажем, с 15 пользователями. Почему SQLite не может быть использован для этого? Посмотрим правде в глаза: по моему профессиональному опыту, пользователи такого типа приложений будут обращаться к базе данных примерно 5-10% от общего времени использования приложения. В остальных 90-95% они просто смотрят информацию на экране, вводят данные в сетке / форме, и когда они сохраняют свои данные, это составляет не более 1 секунды времени базы данных. Fe: 1,5 минуты времени ввода против 1 секунды времени экономии.

Если файл базы данных SQLite заблокирован во время «экономии времени», другие пользователи, которым необходим доступ к базе данных, просто ждут, но они этого не замечают, поскольку время ожидания будет очень маленьким (незаметным). В коде вам просто приходится иметь дело с возможным «загруженным» временем базы данных, чтобы избежать исключений, но это не сложно сделать.

Какой-то парень, который должен думать так же, как я, даже создал клиент-серверное решение для SQLite: SQLitening . Это убедило меня в том, что я не обманываю себя.

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

Многие из наших клиентов не тратят много денег на аппаратное обеспечение, поэтому я часто сталкиваюсь с единственным сервером со всем, что на нем (Exchange, SQL (s), клиенты и т. Д.), И из-за этого почти "задыхаюсь". Если бы я мог доставить продукт, который не предъявляет высоких системных требований, мой клиент был бы счастлив. SQLite не добавляет веса (по крайней мере, немного), MS-SQL делает. Поэтому я бы не стал выбирать SQLite, потому что он бесплатный, дешевый или простой в установке. Я бы выбрал его по практическим / техническим причинам.

К вашему сведению: в моей профессии мы продаем продукты (нестандартные и стандартные, в основном связанные с ERP) клиентам, которые в среднем используют не более 5-6 человек. Есть некоторые исключения, но не более 10-15 пользователей.

Вопрос в том, правильно ли я считаю, что могу использовать SQLite для какого-либо многопользовательского приложения, такого как пример, который я описываю? Есть ли технические недостатки, о которых мне следует знать? Какой ваш опыт (отрицательный или положительный) поможет мне сделать правильный выбор?

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

Есть много случаев, когда SQLite достаточно. Пользователь, отдел или компания редко перерастают его (мы не слышим об этом так часто, потому что никто не звонит программисту, если приложение работает нормально.) Вы можете сделать то же аргумент для файла MS Access (Windows) или SQL Server Compact Edition (требуется некоторая установка). Все они достаточно хороши для локального приложения, потому что вам не нужно заботиться о безопасности файла.

В многопользовательском сценарии в локальной сети файл помещается в общую папку, к которой все пользователи должны получить доступ - безопасность вызовов. Простое обслуживание или любые изменения структуры таблицы, такие как резервное копирование или добавление столбца, будут препятствовать доступу других пользователей. Прошлой ночью резервная копия не работала, потому что кто-то забыл выйти из приложения. Что происходит, когда вы хотите сделать резервную копию в середине дня? Каждый рационализирует, что им не нужны никакие резервные копии в течение дня из-за технических ограничений их базы данных. В какой-то момент установка SQL Server Express / другого аналога на вашем сервере потребует некоторой начальной настройки и настройки безопасности, более сложна заранее, но небольшого обслуживания не потребуется.

Всегда есть проблема масштабируемости / чрезмерного проектирования. Даже если количество пользователей или объем данных по-прежнему поддаются управлению, у кого-то всегда есть идея использовать оперативные данные в некотором интранете или другом интерфейсе веб-сайта / браузера. Файловые базы данных представляют проблемы. Требуется только один человек, который хочет получить доступ к файлу данных через VPN (приложение установлено на их ноутбуке), чтобы решить проблему «масштабирования». Вы можете создать приложение, чтобы позволить отключенным пользователям, которые могут синхронизироваться, когда они вернутся. Похоже, что это не стоит того, чтобы кто-то из офиса отсутствовал.

Я думаю, что это здорово использовать, когда вам нужна «внутренняя» база данных. То есть база данных, с которой будет взаимодействовать ваше приложение / код, но это не будет напрямую связано с основной причиной, по которой ваше приложение существует. Вместо использования огромных отображений в памяти или менеджеров кэша, вы также можете использовать такую ​​базу данных, например. У меня есть очень конкретный пример этого, поскольку я недавно использовал его в тестовых примерах JUnit / DBunit, где мне нужно было подключиться к базе данных, выполнить некоторую работу, прочитать данные и стереть все в конце. Поскольку для создания базы данных вам нужно всего лишь создать пустой файл , это было довольно легко сделать.

Я вижу другое использование: когда у вас есть только один пользователь. Да, это возможно, например, «Firefox» или «Opera» :-)

Кроме того, на веб-сайте SQLite они очень честны по этому поводу и дают основания, когда НЕ ИСПОЛЬЗОВАТЬ ЭТО (см. Параграф «Ситуации, когда другая СУБД может работать лучше»)

ps: относится к комментариям на Sql Server Express, да, его нужно «установить». И у меня были некоторые проблемы с обновлением его лично (мне пришлось вручную удалить некоторые ключи реестра, связанные с предыдущей версией, чтобы иметь возможность установить 2008 R2). Однако, если вы хотите сравнить SQLite с базой данных, разработанной Microsoft, посмотрите на Sql Server Compact Edition , который вам не нужно устанавливать (см. «Развертывание на основе личных файлов»).

Например: рассмотрим приложение ERP, скажем, с 15 пользователями. Почему SQLite не может быть использован для этого?

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

Допустим, у вас есть 100 пользователей, каждый из которых работает в течение 60 секунд, заполняя форму, а затем отправляя ее. Таким образом, вам нужно обрабатывать около 1,6 транзакции в секунду. Модель данных сложна, и сохранение формы включает чтение из многих больших таблиц и запись в них, возможно, даже связь с другой системой, поэтому каждая «отправка формы» приводит к транзакции, которая занимает 2 секунды. Но SQLite не может обрабатывать транзакции одновременно, так что это означает, что он может обрабатывать только 0,5 транзакции на один блок. К сожалению.

«Может быть, боль в установке» не является хорошей причиной, чтобы принять решение против критически важной части инфраструктуры. Кроме того, на выбор есть другие механизмы БД, по крайней мере два из которых (MySQL и Postgres) бесплатны и не имеют ограничений параллелизма SQLite. Их даже проще установить, чем MS-SQL.

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

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

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

Я не считаю SQLite серьезной базой данных, если вы имеете дело с несколькими ГБ данных каждый час. Это становится мучительно медленным и снижает производительность всего приложения. Извините, но я не согласен с вашим увлечением SQLite :-)

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