SQL Server 用户实例中的哪些内容使得它们无法在非 Express Edition 中使用？
经过几年（或更长时间）的开发，我仍然不明白：
- 是什么导致用户实例与 SQL Server 的开发人员（或任何其他）版本不可能/不兼容？
- 为什么开发人员要安装多个（即开发人员版本）SQL Server，因为用户实例只能通过 Express 版本获得？
更新：@Damien_The_Unknowner 在他的回答中写道，
“用户实例很可能是独立的数据库，仅由单个应用程序使用，如果没有该应用程序则毫无意义。”
我是否正确理解了用户实例：
- 需要SQL Server Express 安装程序
- 无法远程连接，
- 用户不能拥有多个这样的实例吗？
- 连接到它们的客户端应用程序是开发工具，例如 VS、SSMS、webadmin、SQL Express 实用程序 等？
我真的不明白何时/为什么/如何在开发环境之外使用/部署它们
After developing for a few years (or more), I still do not understand:
- What makes User Instances impossible/incompatible with Developer (or any other) edition of SQL Server?
- Why has developer to install more than one (i.e. developer edition) of SQL Server because user instances are available only through Express Edition?
Update: @Damien_The_Unbeliever wrote in his answer,
Do I understand correctly that user instances:
- require SQL Server Express setup
- cannot be connected remotely
- the user cannot have more than one such instance?
- the client apps that connect to them are dev tools like VS, SSMS, webadmin, SQL Express Utility, etc?
Really I do not understand when/why/how they can be used/deployed outside of development environment
What are the non-dev cases of SQL Server User Instances (vs CE and other embedded databases)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不认为存在任何技术原因导致用户实例功能不能存在于其他版本中 - 但非快速版本代表了不同形式的预期使用。
用户实例通常是独立的数据库，仅由单个应用程序使用，如果没有该应用程序则毫无意义。
标准/企业版下的数据库预计将作为独立资源进行维护（可能由专门的 DBA），并具有维护计划、计划作业等。他们预计会使用这些版本的附加功能，这对于一个应用程序来控制这些数据库的可用性。
作为开发人员，如果您正在使用两种用法都有意义的系统，则只需要安装这两种方法 - 既构建具有简单数据要求的小型网站，又构建需要更复杂数据库系统的大型系统。
使用用户实例但不是开发工具的应用程序的“典型”示例是一个小型 Web 应用程序。它的 App_Data 文件夹中可能有一个或多个 mdf 文件。它可以从这样的数据库运行诸如其会员系统之类的服务。这种设置的优点是，此类网站的 XCopy 部署足以让整个应用程序准备就绪 - 连接字符串将立即有效。
I don't believe that there are any technical reasons why the user instance functionality couldn't exist in the other editions - but the non-express editions represent a different form of expected usage.
User instances are pretty well expected to be standalone databases, only used by a single application, and meaningless without that application.
Databases under Standard/Enterprise edition are expected to be maintained (possibly by dedicated DBAs) as standalone resources, with maintenance plans, scheduled jobs, etc. They're expected to use additional features of these editions, and it wouldn't make sense for a single application to control the availability of these databases.
And as a developer, you only need both installed if you're working on systems in which both usages make sense - both building small scale websites with simple data requirements, and larger systems that need more complex database systems.
The "typical" example of an application that would use a user instance, but not being a dev tool, would be a small web application. It may have one or more mdf files in it's App_Data folder. It may run such services as its membership system from such a DB. An advantage of such a setup is that an XCopy deploy of such a website is sufficient for the entire application to be ready - the connection string will be valid immediately.