我打算部署一个应用程序，其需求只是数据库的“db_owner”。 数据库本身必须由DBA单独创build。
根据应用程序的工作方式（以及它的简单要求），应该可以在默认实例中创build一个新的数据库，因为每天的写操作（尽pipe经常是这样）（每天写数千次，但是只有几十次读取每天），但每个写都应该很小。
但是，我的团队中的一些人认为，从长远来看，新事物会更好。
如果有人能为我提供一个指导方针，对每个情景的利弊，我会非常感激。
（请原谅我是否有类似的问题;移动的StackExchange应用程序不提供build议的列表，不像网站）。
如果他们只需要db_owner，那么我build议你在现有的实例中这样做。
创build新实例会导致运行所有SQL二进制文件的两个副本的开销。 当SQL可以pipe理服务器的所有可用资源时，SQL最为有效。 多个实例不知道彼此，并可能最终争取可用的资源。 需要更多的configuration来确保您避免性能问题。
创build多个实例的常见原因是1）安全原因2）并行运行两个不同版本的SQL。 你似乎没有这些要求，所以坚持单一的实例。
我的规则是一个例子，除非有一个很好的certificate需要第二个。
这取决于你的场景，但是正如我所知，如果应用程序需要sysadmin或serveradminangular色，就可以部署新的实例。
根据您的要求，不需要新的SQL Server实例因为您不需要不同的SQL Server版本，并且可以在单个SQL Server实例上设置您的安全和权限要求，所以您可以在同一个SQL Server实例上创build新的数据库例
在现有的SQL Server实例上创build一个新的数据库提供了更简单的pipe理（备份，维护，审计，作业执行等），更简单的SQLlogin和angular色pipe理，在SQL Server进程之间提供更less的复杂性，更好的资源使用和分配，更好的性能当从另一个数据库访问一个数据库时（因为它们都在同一个SQL Server实例上）
我的想法是符合上述意见的。 我已经运行了SQL服务器多年，在这些年中，我一直在争取的战斗之一是服务器蔓延。 它总是像这样开始。 我需要一个SQL服务器为我的应用程序。 我的应用程序是低需求，但非常定制的应用程序。 所以我会为每个应用程序创build一个实例。 我为每个应用程序创build单独的实例，以便不同的供应商和我可以通过安装和应用程序修改工作。 而任何应用程序的修改，有时会需要重新启动。 没有像重新启动数据服务器，并重新启动影响服务器上的每个数据库！ 所以为了达到这个目的，实例就是要走的路。事情将会发生。老板会问我是否可以在我的服务器上托pipe别人的数据库。 不，不是他正在寻找的答案。 所以，现在我有另一个我的服务器的数据库，拥有者想要查看他们的数据的权利。 因此，一个困境..我相信这个新的DBA？ 当然不是！ 涉及到数据时，我不信任任何人。 Exs [ecailly我的数据。 所以，我创build了一个单独的实例。 从未见过或曾经使用实例的DBA喜欢这个想法。 他们可以看到他们的数据，重新启动他们的实例。他们对世界感觉很好，他们大声的嘴只是不能帮助，而是告诉某人关于他们的积极经验..而且更多的时候，它的人有一个数据库托pipe问题。所以新的DBA会和其他DBA一起去找我的老板。 该死！ 另一个例子。 不用说，目前，我在我的2014 SQL服务器上运行7个实例，我没有任何问题。 这就是说，我所有的数据库维护成本低，用户不多。 我出于安全原因使用实例，可能需要重新启动的程序，并保持干净。 当涉及像SharePoint这样的大型资源耗尽程序或HR数据库后端时？ 实例不会这样做！ 我将整个SQL服务器专用于这个单独的任务。 最后，如果数据库很小，需求低和/或由多个DBApipe理，则使用数据库实例。 如果数据库支持资源饥渴的怪物，请专门服务器。