话虽如此，我当然可以看到合理的案例，这些观点都不重要。
这并不重要（您可以非常愉快地在同一台机器上使用网络/数据库运行您的网站），这只是扩展中最简单的一步。
这正是 StackOverflow 所做的 - 从运行 IIS/SQL Server 的单台机器开始，然后当它开始变得负载很重时，购买了第二台服务器并将 SQL 服务器移到上面。
如果性能不是问题，不要浪费钱购买/维护两台服务器。
另一方面，参考另一个博客 Scott（Watermasyck，来自 Telligent）——他们发现大多数用户可以通过将数据库与网站放在同一台机器上来加速网站（使用 Telligent 的社区服务器）。但是，在他们的客户的情况下，通常 db 和 web 服务器是该机器上唯一的应用程序，并且网站不会对机器造成太大压力。然后，不必通过网络发送数据的效率更多地弥补了增加的压力。
汤姆在这一点上是正确的。其他一些原因是它不具有成本效益并且存在额外的安全风险。
Web 服务器与数据库服务器有不同的硬件要求。具有大量内存和非常快的磁盘阵列的数据库服务器表现更好，而 Web 服务器只需要足够的内存来缓存文件和频繁的数据库请求（取决于您的设置）。关于成本效益，两台服务器不一定会更便宜，但是性能/成本比应该更高，因为您不必让不同的应用程序竞争资源。出于这个原因，您可能不得不花更多的钱购买一台服务器，该服务器既能满足两者的需求，又能提供与 2 台专用服务器相当的性能。
安全问题是，如果单台机器受到攻击，网络服务器和数据库都容易受到攻击。有了两台服务器，您就有了一些喘息的空间，因为第二台服务器仍然是安全的（至少在一段时间内）。
此外，还有一些可扩展性的好处，因为您可能只需要维护一些由一堆不同的 Web 应用程序使用的数据库服务器。这样，您可以减少应用升级或补丁以及进行性能调整的工作。我相信有一些服务器管理工具可以使这些任务更容易（在单机情况下）。
我认为最大的因素是性能。Web 服务器/应用程序代码和 SQL Server 都会在内存中缓存经常请求的数据，并且通过在相同的内存空间中运行它们会降低缓存性能。
安全是一个主要问题。理想情况下，您的数据库服务器应该位于防火墙后面，只打开执行数据访问所需的端口。您的 Web 应用程序应该使用 SQL 帐户连接到数据库服务器，该帐户具有足够的权限让应用程序运行，仅此而已。例如，您应该删除允许删除对象的权限，并且您肯定不应该使用诸如“sa”之类的帐户进行连接。
如果您的 Web 服务器因劫持而丢失（即完全升级为管理员权限），最坏的情况是您的应用程序的数据库可能会受到损害，但不是整个数据库服务器（如果数据库服务器和 Web 服务器是同一台机器）。如果你已经加密了你的数据库连接字符串并且黑客不够精明来解密它们，那么你失去的只是网络服务器。
尚未提及的一个因素是负载平衡。如果您开始将 Web 服务器和数据库视为独立的机器，您可以优化网络往返次数，并且随着需求的增加添加第二个 Web 服务器或第二个数据库引擎变得更加容易。
我同意 Daniel Earwicker 的观点——安全问题存在很大缺陷。
如果您有一个带有网络服务器的单框设置，并且上面只有该网络服务器的数据库，如果该网络服务器受到威胁，您将丢失网络服务器和该特定应用程序的数据库。
这与您在 2 台服务器设置中丢失网络服务器时所发生的情况完全相同。您丢失了 Web 服务器，只丢失了该特定应用程序的数据库。
在您有 2 个服务器设置的情况下，“维护数据库服务器的其余部分的完整性”的论点是无关紧要的，因为在第一种情况下，与所有其他应用程序（如果有的话）相关的所有其他数据库服务器也不会受到影响- 就像它们一样，被托管在其他地方。
同样，对于 Kev 提出的问题“驻留在数据库服务器上的所有其他数据库怎么样？你失去的只是一个数据库。
相比之下，在 2 服务器设置中，攻击者可以访问 Web 服务器，并通过代理，对数据库服务器的有限权限（在最佳情况下），他们可以通过携带其他应用程序的数据库处于危险之中出慢速、内存密集型查询或最大化数据库服务器上的可用存储空间。通过将应用程序分离到它们自己的关注点中，就像虚拟化一样，您还可以出于安全目的以积极的方式隔离它们。
我可以从第一手经验说，将 Web 服务器和数据库放在不同的机器上通常是一个好主意。如果您有一个资源密集型应用程序，它很容易导致机器上的 CPU 周期达到峰值，从而使机器停止运行。但是，如果您的应用程序对数据库的使用有限，那么让它们共享服务器可能没什么大不了的。
哇，没有人提出这样一个事实：如果您以 5k 美元的价格购买 SQL Server，您可能希望将其用于 Web 应用程序之外的更多用途。如果您使用快递，也许您不在乎。我看到 SQL 服务器为 20 到 30 个应用程序运行数据库，因此将它放在网络服务器上并不明智。
其次，取决于服务器是为谁服务的。我为金融公司和政府工作。因此，我们在只使用存储过程并限制从网络服务器到 SQL 的端口的屁股方法中使用了一种疯狂的痛苦。因此，如果网络应用程序被黑客入侵。黑客唯一能做的就是调用 sprocs，因为网络服务器上的用户帐户被锁定，只能查看/调用 DB 上的 sprocs。所以现在黑客必须弄清楚如何进入数据库。如果它在网络服务器上运行良好，那么它很容易访问。
这取决于应用程序和目的。当高可用性和性能不重要时，不将数据库和 Web 服务器分开也不错。特别是考虑到性能提升 - 如果应用程序进行大量数据库查询，可以通过将其全部保持在同一系统上来消除大量网络负载，从而保持较低的响应时间。
我听了那个播客，很有趣，但安全论点对我来说毫无意义。如果您攻破了服务器 A，并且该服务器可以访问服务器 B 上的数据，那么您立即可以访问服务器 B 上的数据。
我认为这是因为这两台机器通常需要以不同的方式进行优化。除此之外，我不知道，我们在同一台机器上使用服务器数据库运行我们所有的应用程序——当然我们不是面向公众的——但我们没有遇到任何问题。
我无法想象有太多人关心一台机器在两者上都受到损害，因为如果不是数据库内的模式，Web 应用程序通常至少可以不受限制地访问数据。
对别人可能说的话感兴趣。
数据库许可证并不便宜，而且通常按 CPU 收费，因此通过分离 Web 服务器，您可以降低数据库许可证的成本。
例如，如果您有 1 台服务器同时处理包含 8 个 CPU 的 Web 和数据库，则您必须支付 8 个 CPU 许可证。但是，如果您有两台服务器，每台服务器都有 4 个 CPU，并在一台服务器上运行数据库，那么您只需支付 4 个 CPU 许可证
另一个问题是，数据库喜欢占用所有可用内存并保留它以备不时之需。您可以强制它限制内存，但这会大大降低数据访问速度。
认为通过在 Web 服务器上运行数据库服务器可以获得真正的性能提升是一个有缺陷的论点。
由于数据库服务器采用查询字符串并返回结果集，实际从数据服务器流向 Web 服务器的数据相对较少，但处理查询和生成结果集所需的马力相对较大。因此，围绕数据传输时间优化性能是围绕错误的事情进行优化。
在安全性方面，将数据服务器与 Web 服务器放在不同的盒子上是有好处的。拥有这样的设置并不是安全的全部和全部，但它是朝着正确方向迈出的一步。
关于可扩展性，添加 Web 服务器并将它们放入集群以处理增加的流量很容易且相对便宜。添加数据服务器并将它们集群起来并不是那么容易和便宜。此外，Web 服务器和数据服务器具有不同的硬件需求，因此多个盒子有助于提高可扩展性。
如果您从小规模开始并且只有一个盒子，那么使用虚拟机是一个不错的方法。在一台主机上的不同 VM 中运行 Web 服务器和数据服务器，您可以以一个大盒子的价格获得单独盒子的所有收益。
操作系统是另一个考虑因素。虽然您的数据库可能需要更大的内存空间，因此需要 UNIX，但您的 Web 服务器 - 或者更具体地说是您的应用服务器，因为您只提到了两层 - 可能是基于 .Net 的，因此需要 Windows。
行！事情就是这样，将您的数据库服务器安装在另一台机器上并将您的应用程序安装在 Web 服务器上会更安全。然后，您可以使用 Web 链接将您的应用程序连接到数据库。谢谢它。