Почему я должен использовать SQLite поверх базы данных Jet - PullRequest
21 голосов
/ 03 февраля 2009

Кто-то спросил меня об этом на днях, и я не мог придумать хорошего ответа. Переносимость платформы совершенно не имеет отношения к проекту.

Фактически, в Jet есть некоторые функции, которых нет в SQLite, а именно внешние ключи.

Так может ли кто-нибудь подумать, почему вместо базы данных Jet следует использовать SQLite?

Ответы [ 9 ]

23 голосов
/ 12 февраля 2009

Вопреки тому, что говорят другие, Jet не умер и далек от этого: ACE - это новая версия Jet, и она довольно надежна и обратно совместима.

Как SQLite, так и Jet / ACE имеют свои сильные и слабые стороны, и вам необходимо получить больше информации о конкретных моментах, которые важны для вас и вашего приложения.

  • В любом случае вы можете перераспределить двигатель.
  • Jet / ACE немного более интегрирован и поддерживается "из коробки" в инструментах MS и Visual Studio.
  • Jet / ACE имеет более детальную блокировку, что может быть важно, если ваше приложение разрешает многопользовательский доступ или требует многопоточного доступа к базе данных.
  • Jet / ACE имеет больше возможностей с точки зрения того, что вы ожидаете от базы данных (объединения, объединения и сложные запросы).
  • Jet / ACE имеет простой путь миграции на SQL Server, поэтому, если ваша база данных станет большой, вы можете легко перейти на SQL Server.
  • SQLite является кроссплатформенным, поэтому, если ваше приложение необходимо перенести на Linux / Mac под Mono, тогда SQLite - лучший выбор.
  • движок SQLite более жесткий, поэтому перераспределение может быть проще.
  • типы данных в SQLite довольно свободны.
  • SQLite имеет более либеральные права на распространение (так как вы можете делать с ним все, что захотите).

Люди, которые говорят, что Jet портит базы данных, застряли в 1995 году.

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

7 голосов
/ 12 февраля 2009

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

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

Бессерверный аспект SQLite также является существенным преимуществом по сравнению с Jet в том, что на компьютере, на котором будет работать ваша база данных, ничего не нужно устанавливать. Например, я использовал SQLite в веб-приложении ASP.NET, и все, что мне было нужно, это библиотека DLL SQLite (в данном случае это была отличная замена System.Data.SQLite в моем приложении " bin "и моя база данных в папке приложения" App_Data ". Затем я мог загрузить эти файлы на мой веб-хост, и все это «просто сработало». Это без необходимости установки или регистрации чего-либо на целевой машине.

Небольшой недостаток SQLite связан с базой данных на основе файлов. Запись в базу данных блокирует весь файл базы данных, а не конкретную строку или таблицу, тогда как Jet предложит вам более детальный уровень блокировки. Другая небольшая проблема, основанная на тех же основанных на файлах рассуждениях, - это параллелизм, однако сам Jet также не обеспечивает высокий уровень параллелизма.

6 голосов
/ 28 марта 2011

Это все еще вопрос, который возникает время от времени. Я рассматриваю все плюсы и минусы для обоих прямо сейчас для нового проекта. Я пишу множество финансовых приложений, которые имеют дело с денежными ценностями, поэтому одним из наиболее важных «плюсов» для Access / JET / ACE / что бы они ни называли сегодня (я просто называю это Access) являются его сильные типы , Не стоит недооценивать силу наличия сильных типов при работе с деньгами - Access - единственная база данных с одним файлом, которую я видел, с поддержкой типа деньги / десятичный тип, который может хранить РЕАЛЬНЫЕ денежные значения.

Один из моих основных розничных продуктов использует SQLite в качестве бэкэнда, и я могу вам сказать, что у меня практически не было проблем с его развертыванием даже в самых безумных ситуациях. SQLite определенно рассчитан на однопользовательский режим, но у меня МНОГО клиентов, использующих его через SMB. Вы должны записать проверки в свое программное обеспечение, чтобы проверять возвращаемые значения SQLITE_BUSY при выполнении запросов, но если вы завершили это с автоматической повторной попыткой, это «просто работает».

Есть только несколько причин, по которым я бы выбрал Access поверх SQLite - одна из них - это типы данных. Если я когда-нибудь напишу программное обеспечение, которое должно выполнять математические операции с денежными значениями (налоги и т. Д.), Я буду использовать Access. Единственная другая убедительная причина использовать Access - это путь обновления до SQL Server. Поскольку я никогда не использовал SQL-сервер в своей жизни (и не планирую), это не имеет большого значения.

В конце концов, обе базы данных являются чрезвычайно надежными, и я без колебаний использую их в производственной среде. Просто не забудьте использовать правильный инструмент для работы, а иногда это означает, что сервер баз данных (PostgreSQL обращался со мной прямо за последние 13 лет, это точно!).

5 голосов
/ 08 июня 2011

Мы использовали Jet долгое время и недавно перешли на SQLite. Почему?

1: Когда база данных получает около 2 ГБ или при частом использовании, она в конечном итоге повреждается в Jet. Это вызвало у нас много горя! Это не было исправлено в Jet или ACE, хотя у Microsoft есть отдельный инструмент, который может предположительно исправить файлы базы данных.

2: Microsoft несколько лет назад отказалась от Jet в пользу ACE, но если вы прочитаете подробности, Microsoft сама скажет, что ACE НЕ является заменой для Jet, и действительно хочет, чтобы вы вместо этого использовали SQL Server.

3: Jet больше не является стандартной частью Windows, но является частью Microsoft Office, хотя вы можете скачать и установить дистрибутив. Однако нельзя одновременно устанавливать 32- и 64-разрядные движки. Если у вас установлена ​​32-разрядная версия Office 2007 и вы пытаетесь установить 64-разрядную подсистему ACE, она говорит, что вам нужно сначала удалить Office 2007.

Так что по этим причинам мы просто решили, что достаточно. Установка SQL Server не является решением, потому что это большая сложная инвазивная установка и не очень переносимая.

Наше программное обеспечение C ++ напрямую поддерживает SQLite через файл sqlite3.c, и оно работает очень хорошо. Я реализовал предварительные интерфейсы для OCILIB, Oracle, SQL Server, MySQL и т. Д., И это был один из самых простых. Это также намного быстрее, чем Jet, и в результате файлы могут составлять треть размера Jet. У нас есть некоторый код VB6, VBA и .NET, который также должен использовать файлы нашей базы данных, и для этого мы используем драйвер ODBC для SQLite (просто Google его). Хорошо работает.

SQLite отлично работает как в 32-х, так и в 64-битных системах. И если вы прочитаете это, то увидите, что оно серьезно протестировано и удивительно стабильно. Он также поддерживает более стандартный SQL и ближе к Oracle / SQL Server, чем Jet.

4 голосов
/ 03 февраля 2009

Jet больше не поддерживается. SQLite также проще в установке, так как это одна библиотека, которая может быть легко упакована с вашим приложением. Использование SQLite также может предотвратить блокировку вендера, просто потому, что переносимость языка или кроссплатформенности теперь не является проблемой, не означает, что она не станет такой позже. Подробнее об уходе Джета http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine

2 голосов
/ 03 февраля 2009

SQLite - это новый Jet. Даже если кроссплатформенность не имеет отношения к вам, это может не относиться к вашим клиентам. Использование Jet блокирует их в Windows и в более не поддерживаемой БД, что ни к чему хорошему. И SQLite работает практически с любой средой разработки.

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

Вы, безусловно, можете создавать внешние ключи в SQLite, а в SQLite 3.6.19 также были добавлены ограничения внешнего ключа.

2 голосов
/ 03 февраля 2009

Стоимость не является проблемой. Если ваш интерфейс встроен в нечто иное, чем MS-Access, пользователи приложения не должны платить никаких сборов за установку драйверов Jet. Visual Studio будет включать эти драйверы во время сборки (по крайней мере, в предыдущих версиях .NET.).

Полагаю, у вас нет личных предпочтений и вы одинаково опытны в разработке в любой среде. Если у ваших пользователей уже есть лицензии MS-Access, и они хотели бы иметь возможность писать свои собственные отчеты (О, не дай Бог, любой нехакер, пытающийся совершить такой огромный подвиг!), Используйте Jet.

0 голосов
/ 17 сентября 2013

Если вы хорошо программируете на Python, Pearl, Lua или многих других языках, естественным выбором будет SQLite.

0 голосов
/ 03 февраля 2009

С макушки головы, это бесплатно и кроссплатформенно; но более важно ... как вы думаете, он более стабильный и масштабируемый, чем Jet / MS Access / .mdb? Будет ли он дольше прожить, что его преемник (ACE / .accdb)

Если его используют не только пара человек, я не беспокоюсь о Jet. Я иду прямо к MS-SQL (даже в бесплатной версии). Это просто не стоит боли испорченной БД (которой известен Jet - хотя, возможно, они это исправили - я не хочу быть их тестовым примером).

...