SQL Server 2012 LocalDb 共享访问

Question

我正在考虑在我的应用程序中添加用于数据存储的 LocalDB。

背景：

1) 我的应用程序有 2 个部分。 一种。桌面客户端。 （在登录电脑的用户下运行） 湾。新台币服务。 （作为本地系统运行）

新台币服务： 1) 对我们的后端服务器进行 Web 服务调用，以获取客户端特定的设置和配置选项。
2) 上传客户端创建的记录。

桌面应用程序： 1) 加载 NT 服务下载的设置并根据这些设置运行。 2) 创建客户记录。

LocalDB 在这里看起来很合适，但是这两个项目可以同时访问 LOCALDB 吗？经过一些在线调查后，看起来 LOCALDB 共享实例可能是可能的。但是，这是否意味着 NT 服务必须始终保持 LOCALDB 连接处于活动状态？

Answer 1

已经完成了与您所描述的非常相似的部署，是的，可以这样做。但是我强烈建议不要这样做。

一些想法：

1. Lo​​calDB 'instances' 需要加载用户配置文件。始终加载的唯一使用配置文件是本地系统，即 NT Authority\SYSTEM 帐户。
2. 只有“实例”的所有者可以启动或停止它。 'automagic' 实例可以设置为忽略自动摊牌超时，但它仍然必须至少启动一次。我通过创建一个 Windows 任务解决了这个问题，该任务启动了一个引导程序，该引导程序在引导时输出“sqllocaldb start v11.0”。 Windows 任务以“Below Normal”进程优先级执行，因此启动的引导程序实际上将 SQLEnv.exe 优先级提高到了我的用例的高。
3. 假设您使用 NT Authority\SYSTEM 作为实例配置文件，使用 SQL Management Studio 之类的东西可能需要系统上的 PsExec。这是一个安全风险，因为它使您可以交互式访问作为本地系统运行的进程。不要这样做。
4. 我们使用组来访问我们的客户端部分，因此我们授予这些组对实际数据库/实例的访问权限。否则，几乎不可能授予新用户访问实例/数据库的权限。

您真的需要一个数据库，或者胖客户端是否可以为每个记录写出一个文件到特定位置，然后服务会检查（或构建一个缓冲区）并在途中发送？

另一种选择是删除 NT 服务并使其功能成为客户端启动过程的一部分。为什么有一个长时间运行的进程不断检查配置更改，并且只有在用户积极使用系统时才推送数据？假设您没有需求/现有系统。