Почему я должен использовать SQLite поверх базы данных Jet
Кто-то спросил меня об этом на днях, и я не мог придумать хорошего ответа. Переносимость платформы совершенно не имеет отношения к проекту.
Фактически, у Jet есть некоторые особенности, которых нет у SQLite, а именно внешние ключи.
Так кто-нибудь может подумать, почему SQLite следует использовать вместо базы данных Jet?
9 ответов
Вопреки тому, что говорят другие, 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 году.
В конце концов, если ваше приложение не имеет каких-то очень специфических требований, которые раздвигают границы любого из механизмов баз данных, то, вероятно, не имеет значения, какой из них вы выбрали.
Просто используйте тот, который вам проще всего включить в ваш проект.
SQLite превосходит Jet по основной причине, что SQLite совместим с ACID, а Jet, к сожалению, нет. Если целостность данных является проблемой, SQLite предлагает гораздо более "надежную" платформу для ваших требований к хранению данных. См. "SQLite is Transactional" и "Atomic Commit In SQLite" для получения более подробной информации.
В SQLite действительно отсутствуют некоторые функции (например, внешние ключи), однако они связаны, прежде всего, с тем, что SQLite специально разработан как чрезвычайно небольшая и легкая база данных, которая также не требует сервера.
Безсерверный аспект SQLite также является существенным преимуществом по сравнению с Jet в том, что на компьютере, на котором будет работать ваша база данных, ничего не нужно устанавливать. Например, я использовал SQLite в веб-приложении ASP.NET, и все, что мне было нужно, - это DLLite SQLite (в данном случае это была отличная замена System.Data.SQLite) в папке "bin" моего приложения, и мой базы данных в папке приложения "App_Data". Затем я мог загрузить эти файлы на мой веб-хост, и все это "просто сработало". Это без необходимости фактически устанавливать или регистрировать что-либо на целевой машине.
Небольшой недостаток SQLite связан с базой данных на основе файлов. Запись в базу данных блокирует весь файл базы данных, а не конкретную строку или таблицу, тогда как Jet предложит вам более детальный уровень блокировки. Другая небольшая проблема, основанная на тех же основанных на файлах рассуждениях, - это параллелизм, однако сам Jet также не обеспечивает высокий уровень параллелизма.
Это все еще вопрос, который возникает время от времени. Я рассматриваю все плюсы и минусы для обоих прямо сейчас для нового проекта. Я пишу множество финансовых приложений, которые имеют дело с денежными ценностями, поэтому одним из наиболее важных "плюсов" для Access/JET/ACE/ что бы они ни называли сегодня (я просто называю это Access) являются его сильные типы, Не стоит недооценивать силу наличия сильных типов при работе с деньгами - Access - единственная база данных с одним файлом, которую я видел, с поддержкой типа деньги / десятичный тип, который может хранить НАСТОЯЩИЕ денежные значения.
Один из моих основных розничных продуктов использует SQLite в качестве бэкэнда, и я могу вам сказать, что у меня практически не было проблем с его развертыванием даже в самых безумных ситуациях. SQLite определенно предназначен для однопользовательского режима, но у меня МНОГО клиентов, использующих его через SMB. Вы должны записать проверки в свое программное обеспечение, чтобы проверять возвращаемые значения SQLITE_BUSY при выполнении запросов, но если вы завершили это с автоматической повторной попыткой, это "просто работает".
Есть только несколько причин, по которым я бы выбрал Access поверх SQLite - одна из них - это типы данных. Если я когда-либо пишу программное обеспечение, которое должно выполнять математические расчеты по денежным значениям (налог и т. Д.), Я буду использовать Access. Единственная другая убедительная причина использовать Access - это путь обновления до SQL Server. Поскольку я никогда не использовал SQL-сервер в своей жизни (и не планирую), это не имеет большого значения.
В конце концов, обе базы данных являются чрезвычайно надежными, и я без колебаний использую их в производственной среде. Просто не забудьте использовать правильный инструмент для работы, а иногда это означает, что сервер баз данных (PostgreSQL обращался со мной прямо за последние 13 лет, это точно!).
Мы долгое время пользовались 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.
Jet больше не поддерживается. SQLite также проще в установке, так как это одна библиотека, которая может быть легко упакована с вашим приложением. Использование SQLite также может предотвратить блокировку вендера, просто потому, что переносимость языка или кроссплатформенности теперь не является проблемой, не означает, что она не станет такой позже. Подробнее об отставке Джета см. http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
SQLite - это новый Jet. Даже если кроссплатформенность не имеет отношения к вам, это может не относиться к вашим клиентам. Использование Jet блокирует их в Windows и в более не поддерживаемой БД, что ни к чему хорошему. И SQLite работает практически с любой средой разработки.
Jet известен своими странными проблемами с коррупцией, поэтому я стараюсь держаться от него подальше.
Вы, конечно, можете создавать внешние ключи в SQLite, а с SQLite 3.6.19 также были добавлены ограничения внешнего ключа.
Стоимость не проблема. Если ваш интерфейс встроен в нечто иное, чем MS-Access, пользователи приложения не должны платить никаких сборов за установку драйверов Jet. Visual Studio будет включать эти драйверы во время сборки (по крайней мере, до версии.NET.).
Я предполагаю, что у вас нет личных предпочтений и вы одинаково опытны в разработке в любой среде. Если у ваших пользователей уже есть лицензии MS-Access, и они хотели бы иметь возможность писать свои собственные отчеты (О, не дай Бог, любой нехакер, пытающийся совершить такой огромный подвиг!), Используйте Jet.
Если вы хорошо программируете на Python, Pearl, Lua или многих других языках, SQLite будет естественным выбором.
С головы до головы, это бесплатно и кросс-платформенный; но важнее... как вы думаете, он более стабильный и масштабируемый, чем Jet/MS Access/.mdb? Будет ли он дольше прожить, что его преемник (ACE/.accdb)
Если его используют не только пара человек, я не беспокоюсь о Jet. Я иду прямо к MS-SQL (даже в бесплатной версии). Это просто не стоит боли испорченной БД (которой известен Jet - хотя, возможно, они это исправили - хотя я не хочу быть их тестовым примером).