这个问题的灵感来自我近一年前提出的一个问题 - any-orms-that-work-with-ms-access-for-prototyping - 最近再次变得活跃，但是作为Access与SQL Server的争论。
似乎有很多Access仇恨者，主要说唱似乎是它不能很好地扩展（虽然有些人似乎已经能够使它工作）。
对于那些使用过这两种技术的人来说，是否存在使用Access over SQL Server的情况？
为什么呢？
你怎么能提高你成功的几率？
例如，在具有一个或少量用户的桌面应用上，Access可能是更好的选择吗？
或者，要采取反向措施，何时避免从开始进入？
再次，为什么？
修改当我说“访问”时，我想获得有关两件事的反馈：
仅使用数据库组件（Jet / ACE）
使用应用程序开发功能（报告，脚本等）
毕竟，如果您的应用程序可以忍受数据库端的限制，那么使用某些app dev功能可能会有一些优势。
（仅供记录，我在这场比赛中没有狗 - 我是一个满意的SQLite用户。）
答案 0 :(得分：7)
是否存在使用Access over SQL Server的情况？
当我不想成为支持它的人时。
访问很常见，管理比SQL Server少。客户找到能够维持设置的人的机会更好，获得培训的成本更低（大多数大专院校和娱乐中心都有课程）。
在具有一个或少数用户的桌面应用上，可能是更好的选择吗？
据我所知，如果两个或更多人可以在同一时间更新同一记录，那么Access仍然不是一个好选择。根据SQL Server Express或Compact Editions，PostgreSQL或MySQL等免费选项，对需要控制的最终用户征税（尽管他们可能真的不应该使用它，但为了非规范化数据）。
什么时候应该从get go中避开Access？
当识别出数据的重要性时，以及数据迁移的影响。
除了免费之外，我还推荐使用SQL Server Express Edition，因为您可以将版本作为插件替换。同样适用于Oracle Express Edition。在上述任何一个之后，PostgreSQL将是我的下一个建议; MySQL落后于开发人员功能，与PostgreSQL不同 - 可能需要商业许可证。
答案 1 :(得分：3)
我会回答你要问的问题，而不是你实际发布的问题（你的意思是Jet / ACE，而不是Access）。
是的，有很多环境，Jet / ACE是一个合适的数据存储。我想说的主要问题是你将拥有多少用户。对于任何高达15-20的用户，Jet / ACE都可以正常工作。如果你不知道自己在做什么，唯一不会出现的情况就是这样。你可能没有线索：
您使用表格和表格/报告等创建单个单片MDB / ACCDB文件。
您尝试在多个用户之间共享该单个整体文件。
您明智地将数据库应用程序拆分为前端（表单/报告/等）和后端（仅限表），但尝试在多个用户之间共享前端。
所有这些场景都是失败的方法，但是Jet / ACE并不是错误的，而是那些从不费心学习如何设计和分发Access应用程序的白痴。
性能较差的Access应用程序的另一个常见特征是将表单绑定到完整表而不是选定的记录子集。基本上，您将应用程序设计为一次检索最少量的数据，以便允许用户完成她的工作。例如，编辑一条记录的用户不需要在表单后面加载其他10000条记录。
所有这一切，如果这些用户没有处于繁重的数据输入/编辑模式，那么具有Jet / ACE后端的Access应用程序仍然可以与超过15/20的用户一起使用。如果主要是只读用户，则最多可以支持50个用户。
然而，如果我处于这种情况，我可能会开始敦促升级到SQL Server。但需要注意的是，与后端的简单文件相比，SQL Server会增加大量的管理开销。使用完整的SQL Server比使用SQL Server Express更容易实现这些任务的自动化，因此对于那些不熟悉编写和安排自己的SQLCmd脚本的人来说，使用SQL Server Express的建议并不是一个很好的建议。 / p>
安全性也可能更复杂。这是因为您可以使用SQL Server安全性做更多的事情，但在升迁时仍需要在前端解决。
在可以使用管理专业知识的环境中，您可以使用多个用户作为决定何时升迁的唯一基准。在缺乏专业知识和基础设施的小型办公室中，通常可以更好地利用资源来尽可能长时间地使用Jet / ACE。
对于它的价值，我有十几个活跃的客户端使用Access应用程序，目前只有两个针对SQL Server运行。其余的只有两个甚至是候选人，并且没有太多令人信服的理由来扩大它们，因为它们是小用户群并且没有性能或可靠性问题，并且没有重大的安全问题。
这实际上提出了其他几点：
如果这些问题中的一个或多个很重要，SQL Server可能更适合单用户应用程序：
数据非常敏感，需要保证超出Jet / ACE的可能性。基本上，如果您需要的数据超出了Excel电子表格的保护范围，则需要基于服务器的数据库引擎。
一些应用程序会破坏如此多的数据，以至于它们真正受益于服务器数据库引擎，无论是容量还是能够将数据库操作切换到完全不同的CPU。
某些应用程序需要全天候可用，无需停机或任何丢失甚至1字节数据的风险都是可以接受的。在这种情况下，建议使用基于服务器的数据库。
根据我的经验，大多数人都非常高估了他们对这三者的需求，并低估了Jet / ACE处理数据和保持可靠性的能力。
编辑：对我而言，一个场景对Access很有吸引力。
假设您有一个没有文件服务器的3人办公室，只有3台电脑。你能不能：
告诉他们购买独立服务器，将其配置为SQL Server（也可能作为文件服务器），然后让他们使用它。
在一个对等工作站上安装SQL Server，让他们使用针对它运行的应用程序。
只需使用Access。
在前两种情况下，需要进行更多维护和管理（尽管您的Jet / ACE后端也需要维护）。谁会这样做？
如果你选择＃1，该服务器的资金将用于何处以及设置它的劳动力以及随着时间的推移维护和管理它的劳动力？
如果您选择＃2，那么如果没有足够的工作站充当SQL Server和工作站，该怎么办？
答案 2 :(得分：3)
正如其他人所说，有明显的情况是访问不适合工作，有些情况下很好，我想在工作中与你分享一个边界线案例。
我制作了一套相当漂亮的应用程序，它们共同协作并提供许多功能，例如质量评审，书面程序跟踪，违规记录，班次安排和呼叫中心操作。应用程序都有单独的后端，但有些后端变得非常大。
现在，在我的工作中，我支持两个站点，每个站点在不同的网络上，并由不同的IT部门控制它们。在我最努力的一面，我们设法按下旧的戴尔服务器运行SQL Server 2008R2，生活很好，我启动了项目，将这些应用程序（都是未绑定的）升迁到SQL服务器。
时间过去了，我们在SQL端发布了新版本，用户很高兴处理时间从大约2秒减少到大约0.3秒。另外，我可以开始添加新功能。
然而，另一方甚至不会接受运行数据库的SQL服务器盒（甚至虚拟机箱）的概念，该数据库不是在IT的象牙塔中设计的。因此，它们仍然停留在较旧的访问版本上，这种版本仍然可以正常工作，只是速度较慢。
这是一个几乎完美的A / B测试情况，应用程序处于“需要”扩展的边界线并且已经证明了好处，但访问仍然正常。通过仔细的编码和足够好的文件服务器访问可以做出令人惊讶的事情。
作为SQL服务器端的另一个侧面说明我不得不设置另一个单独的应用程序，因为它只被5个左右的人使用，我坚持在访问/ jet中执行它而不接触SQL服务器，所有关于使用正确的工具的工作。我经常想到这些IT用户认为访问只适合一个用户并且每次都要推送服务器后端作为携带大锤的人的类型，以防他们需要打开几个核桃
答案 3 :(得分：3)
我不希望再次将访问权作为开发工具。 Horrid（部分是因为我是从VB来的，但主要是因为它很可怕）。即使前端（应用程序）和后端（只是数据）正确分割，它仍然是一种痛苦和版本控制的猪（可能，但非常不愉快）。当然，最新的化身可能都是固定的......但是我无意找出何时可以用其他工具做得更好的前端。
另一方面
Jet / ACE为各种类型的应用程序提供了相当不错的数据存储
所以...我现在会用它吗？嗯，不，不再 - 世界已经发展，现在存在更好的替代方案 - 不再紧凑和修复。
是的，.NET程序员（ - ：
答案 4 :(得分：2)
喷气/ ACE
访问
虽然我的标准范围似乎很窄，但我发现大多数业务需求都得到了处理。你很幸运，如果你继续经营，更不用说增长Access了。当大多数企业需要扩展到Access以外（开发团队也在增长）时，他们的业务规则往往会发生巨大变化，无论如何都会重写许多应用程序，但最初的Access应用程序将满足许多要求。 / p>
答案 5 :(得分：1)
我会在以下任何一种情况下使用Access over SQLServer：
答案 6 :(得分：1)
Access是一种应用程序开发工具。 SQL Server是一个DBMS。他们不是一回事！
但是，您可能会问是否有任何理由选择文件共享数据库体系结构（如Jet / ACE）而不是客户端服务器（如SQL Server）。我认为没有很好的技术原因，除了非常琐碎的单用户桌面使用的边缘情况。客户端 - 服务器在TCO，可伸缩性，可管理性，可用性，安全性以及其他所有方面都非常出色。出于其他原因，客户端 - 服务器DBMS可以更好地满足大多数企业环境的需求。
也许人们现在选择文件共享模型的主要原因可能不是因为它有任何固有的优势。更有可能的是，因为他们拥有现有的应用程序基础，而且人们已经以这种方式工作，并且没有动力进行更改。
答案 7 :(得分：1)
我推荐Access用于较小的，单一用途的单用户需求。就我而言，我使用Access从几个SQL Server获取数据，查询数据，对数据进行排序，最后通过电子邮件发送数据。
当然，这并不完美，但实际上并没有有能力的软件。
答案 8 :(得分：1)
我可以设想任何我都不愿意部署基于Access的应用程序的情况。
我曾经说过没有Access的功能“哇，我希望我拥有它！”
然而，另一方面，大约每年一次，在一些小丑将一个Access应用程序整合到一家公司中后，我被召唤来接收这些产品。通常这发生在他们最不合时宜的时间。
事实上，我们构建的应用程序倾向于坚持一段时间。无论你建造什么，很可能在你继续前进很久之后仍然存在。而且，在某些时候，这些应用程序在公司的生活中变得如此根深蒂固，以至于它们真正成为关键任务。特别是对于那些缺乏资源的小公司来说，让全职开发人员不断创新。
所以，从现在起5年后，运行这个小型Access应用程序的公司可能会增长。你必须要问自己的问题是，你是将它们定位于增长还是通过选择一种无法实现增长的技术来故意阻碍增长？
考虑到您无法在没有时间投资的情况下将Access切换为由SQL服务器支持，后一种路由可确保他们必须花费大量资源来替换它。
有些开发者可能并不关心;我做。
答案 9 :(得分：1)
无法确定所有潜在客户是否已购买MS Access（MS Office）。可以基于SQL Sever创建免费解决方案，但不能创建Access。
无法创建用于从互联网进行公共访问的Web应用程序，因为在这种情况下，只有在验证用户购买了MS Access许可证后才能使用webapp。
此外，MS Access不适用于无人值守（非用户交互）处理[1]：
Plz检查[1]中“使用服务器端自动化办公室的问题”部分中的问题的枚举
<强>更新
David-W-Fenton指出MsAccess2007运行时是免费的
我相信，大多数人使用（并希望）MSAccess，首先，因为他们习惯于将Access作为客户端（GUI前端）而不是由于服务器部分（运行时）。
所以，让我们总结一下：
MsAccess运行时开始是免费的（尽管大多数人使用2007之前的Access并且没有看到升级的任何令人信服的理由）但是对于无人参与的参与没有意义，即当基于MSAccess的产品供内部使用时（不用于销售和然而，无论如何已经买了。
作为前端/ GUI /客户端的MsAccess，当基于MsAccess的软件产品的分发和销售有意义时，并不是免费的。
是不是赶上了22（赶上33？）的情况？
MsAccess（MsOffice）不是用于开发独立软件产品的AD / IDE（开发工具或平台），也没有免费版本。我认为它根本不是开发平台。 VBA，MsOffice开发工具和功能仅作为MS最终用户产品（MS Office）的支持功能。未经供应商MS许可/许可，不得重复使用它们。他们的内部和规范不属于公共领域 - 一半记录，更改，恕不另行通知，不能重做/开源/重新实现。
无法开发基于MSAccess的产品，希望分发，销售，展示免费版本甚至是客户维护，而无需客户首先购买MsAccess许可证。
UPDATE2
早在2002年，我就开发了无人值守的后备应用程序。要求是支持Access97和Access2000。我在Jet驱动程序中遇到了严重错误，当我向MS报告时，答案是它不再受支持了。这是一个死锁 - 无证的封闭“平台”，其中包含错误和不可预测的不稳定行为+不再支持。
我想，对于最近的MsAccess-es活动来说，风险也是一样的。
[1]
办公室服务器端自动化的注意事项
http://support.microsoft.com/kb/257757
答案 10 :(得分：1)
我曾经认为ACE / Jet是一个整洁的小巧的SQL产品。虽然我从未想过它与SQL Server差不多，但是ACE / Jet可以做的事情是SQL Server无法做到的：[思考片刻......] CHECK支持子查询的约束例如，具有多个级联路径的FK。这些在原型设计时非常有用，无需实施变通方法。
我从未选择在生产中使用ACE / Jet。我支持的系统确实使用它总是遇到困难问题，当手动执行“紧凑和修复”时几乎总是消失，这表明该技术存在根本性缺陷。哦，是的，毫无疑问，我们犯了一些可怕的错误，但我们都是有能力的SQL编码员和软件工程通才，我们似乎没有做错任何事情（我们当然没有兴趣投资Access专家）。我听说过数百次类似的经历。
我一直遇到的一个大问题是微软缺乏关于ACE / Jet的良好文档。上次我查看（Access2007）时，Access帮助包含的SQL语法在产品中没有也从未存在过，但与缺少的信息相比却相形见绌。我有我特别喜欢的东西，我可以忍受你，但采取一些简单和基本的东西，如数据类型优先或十进制舍入行为，你会发现在这些规则的文档中徒劳无功。在SQL Server中，许多基本规则都可以在SQL-92标准规范中找到，但遗憾的是ACE / Jet从来没有，也永远不会符合SQL-92。
我根本不再使用ACE / Jet。 SQL Server现在可以使用SQL做的事情远远超过ACE / Jet可以做的事情 - 如果没有包含SQL-92兼容性，公用表表达式，多语句存储过程，{{1数据类型，窗口集函数，DATE子句，......这么多的东西立即浮现在脑海中！
SQL Server是比ACE / Jet更具动态性的产品。作为最终用户，我（感觉我）可以参与塑造其未来：我可以报告错误并从开发团队获得及时的反馈;我可以投票修复错误。 SQL Server帮助（BOL）非常出色并包含社区内容。相比之下，Jet近十年没有获得新功能，那么ACE带来了很多很酷的功能......对于SharePoint！我无法报告ACE / Jet错误（我将从哪里开始！）并且无论如何都无法修复它们，因为MS不会为最终用户投资ACE / Jet。我甚至无法让他们纠正Access帮助中的明显错误。
我建议ACE / Jet比SQL Server更好的选择是你已经投入ACE / Jet并且你不准备改变的唯一情况。我想起了Jeremy Clarkson quote，“人们的载体是为那些已经放弃的人”。
答案 11 :(得分：0)
许多工程应用程序使用JET数据库来获取配置信息。可以把它想象成类固醇的ini文件。我需要链接表，但仅限单用户，每个用户都需要自己的可移植mdb文件。我的主应用程序是一个绘图程序，其中信息是不同的绘图设置，每个都有多个通道，包含必须链接到当前绘图的子表中的信息。但是，我使用的商业工程软件也将设置存储在mdb文件中，因此我的方法并不是唯一的。我知道这种方法会使大多数IT专业人员感到困惑，因为不是数据库的正常业务应用程序微软似乎也毫无头绪，因为他们认为SQL Server对一切都更好，并试图强制要求。目前，我正在研究SQL Compact，因为我想要一个不需要PC设置的单一文件解决方案。 JET对我来说很好，但微软在64位上很难，并且要求解决方案与Office 32位共存。对不起，如果我的需求超出了舒适区或专业开发人员。