当前位置:  开发笔记 > 编程语言 > 正文

为什么我应该在Jet数据库上使用SQLite

如何解决《为什么我应该在Jet数据库上使用SQLite》经验,为你挑选了4个好方法。

前几天有人问过我,我想不出一个好的答案.平台可移植性与项目完全无关.

事实上,Jet有一些SQLite没有的功能,即外键.

那么有谁能想到为什么应该使用SQLite而不是Jet数据库呢?



1> Renaud Bompu..:

与其他人所说的相反,Jet并没有死,而且远非如此:ACE是Jet的新版本,它非常强大且向后兼容.

SQLite和Jet/ACE都有自己的优点和缺点,您需要获得有关对您和您的应用程序很重要的特定点的更多信息.

在任何一种情况下,您都可以重新分配引擎.

Jet/ACE在MS工具和Visual Studio中开箱即用,更加集成和支持.

Jet/ACE具有更精细的锁定,如果您的应用程序允许多用户或需要对数据库进行多线程访问,这可能很重要.

Jet/ACE在数据库(连接,联合和复杂查询)方面具有更多功能.

Jet/ACE具有到SQL Server的简单迁移路径,因此如果您的数据库需求变大,您可以非常轻松地迁移到SQL Server.

SQLite是跨平台的,所以如果您的应用需要在Mono下移植到Linux/Mac,那么SQLite是更好的选择.

SQLite引擎更紧密,因此重新分发可能更容易.

SQLite中的数据类型非常松散.

SQLite拥有更自由的再分配权利(因为你基本上可以随心所欲地做任何事情).

那些说Jet破坏数据库的人在1995年陷入困境.

最后,除非您的应用程序有一些非常具体的要求正在推动任一数据库引擎的界限,否则您选择哪一个并不重要.
只需使用最容易包含在项目中的那个.


@David:在某些情况下可能无关紧要,如果您使用的是ORM,它通常会为您处理这些问题.所有这些数据库都有一个位置,您只需要选择对您的项目最有意义的数据库.
外键约束必须在数据库引擎本身中强制执行,而不是在它之上的某个级别(在应用程序级别或在应用程序和数据库之间的层中).令我感到震惊的是,在这个较晚的日期,任何人都会试图证明在数据库引擎本身以外的任何地方执行关系完整性.对我来说根本没有意义.

2> CraigTP..:

SQLite优于Jet,主要原因是SQLite 符合ACID标准,而不幸的是,Jet不是.如果数据完整性是一个问题,SQLite为您的数据存储需求提供了一个更加"强大"的平台.有关更多详细信息,请参阅"SQLite Is Transactional"和"SQLite中的原子提交".

SQLite确实缺少一些功能(例如外键),但是,这些主要是由于SQLite被专门开发为一个非常小且轻量级的数据库,也是无服务器的.

SQLite的无服务器方面也是Jet的一个主要优点,因为不需要在运行数据库的机器上安装任何东西.例如,我在ASP.NET Web应用程序中使用了SQLite,我需要的只是SQLite DLL(在这种情况下是我的应用程序的"bin"文件夹中的优秀System.Data.SQLite替代品),而我的应用程序的"App_Data"文件夹中的数据库.然后我可以将这些文件上传到我的虚拟主机,这一切都"正常".这无需在目标计算机上实际安装或注册任何内容.

SQLite的一小部分是由于数据库是基于文件的.数据库写入将锁定整个数据库文件而不是特定的行或表,而Jet将为您提供更精细的锁定级别.基于相同的基于文件的推理的另一个小问题是并发性,但Jet本身也不提供高级别的并发性.



3> Mitchell V..:

这仍然是一个不时出现的问题.我正在考虑现在为一个新项目的所有利弊.我写了很多的金钱价值观应对金融应用中最重要的"利弊"的Access/JET/ACE /不管不着痕迹呼-IT-今日(我只是把它接入),这样一个是它的强类型.不要小看有,当你与金钱打交道强类型的电源 - 访问是我见过有能存储真金白银值货币/ decimal类型支持的唯一单文件数据库.

我的一个主要零售产品使用SQLite作为后端,我可以告诉你,即使在最疯狂的情况下我也几乎没有问题.SQLite绝对是单用户设计的,但我有很多客户通过SMB使用它.你必须在你的软件中写入检查,以便在运行查询时检查SQLITE_BUSY的返回值,但是如果你用自动重试来包装它,那么它"正常工作".

我选择Access over SQLite只有几个原因 - 一个是数据类型.如果我一直在编写必须对货币价值(税等)进行数学计算的软件,我将使用Access.使用Access的唯一其他令人信服的理由是SQL Server的升级路径.因为我一生中从未使用过SQL服务器(并且不打算这样做),所以这不是什么大问题.

最后,两者都是非常强大的数据库 - 我会毫不犹豫地在生产环境中使用它们.只记得使用正确的工具来完成工作,有时这意味着数据库服务器(PostgreSQL在过去的13年里一直对我这么做,这是肯定的!).



4> Kharina Tige..:

我们使用Jet很长一段时间,最近切换到了SQLite.为什么?

1:当数据库接近2 GB或经常使用时,它最终会在Jet中损坏.这给我们带来了很多悲伤!虽然微软有一个单独的工具可以修复数据库文件,但这在Jet或ACE中尚未修复.

2:微软几年前不赞成使用Jet,而是赞成ACE,但如果你阅读了细节,微软本身就说ACE不是jet的替代品,而且真的希望你使用SQL Server.

3:Jet不再是Windows的标准部分,而是Microsoft Office的一部分,尽管您可以下载并安装可分发的.但是,您不能同时安装32位和64位引擎.如果您安装了Office 2007 32位,并且尝试安装64位ACE引擎,则会告诉您需要先卸载Office 2007.

所以出于这些原因,我们刚刚决定足够了.安装SQL Server不是一个解决方案,因为它是一个复杂的大型入侵安装,并不是非常便携.

我们的C++软件通过sqlite3.c文件直接支持SQLite,它运行得很好.我已经为OCILIB,Oracle,SQL Server,MySQL等实现了动态接口,这是最简单的接口之一.它也比Jet快得多,结果文件可能是Jet大小的三分之一.我们确实有一些VB6,VBA和.NET代码也需要使用我们的数据库文件,为此我们使用SQLite ODBC驱动程序(只是Google).效果很好.

SQLite在32位和64位都可以正常工作.如果您阅读它,您将看到它经过严格测试并且非常稳定.它还支持更多标准SQL,并且比Jet更接近Oracle/SQL Server.


你的#3错了.Jet 4仍然是Windows的一部分,自从Windows 2000以来它一直被Active Directory使用.我确实希望尽快改变,因为64位问题(即Jet 4永远不会是64位,这意味着任何组合都取决于它必须是32位).Jet 4不是由Office开发团队管理,而是由Windows团队管理.它是ACE,Jet 4的分支(可能被称为Jet 4.5或Jet 5),由Access开发团队(不是Office团队)拥有,并将继续在自己的路径上开发.
2GB限制适用于ACE和Jet 4,在我看来也不太可能改变.我从未将其视为一个问题,因为从我的角度来看,适合Jet/ACE数据存储的应用程序永远不会那么大.如果我有一个应用程序,数据存储开始接近1GB,我会立即升级.如果你在生产使用中遇到2GB的限制,它会向我提出两件事:1.你没有进行任何数据库维护(常规紧凑),2.你首先选择了错误的数据存储.
推荐阅读
牛尾巴2010
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有