为什么sql需要服务器？

我是SQL新手，我正在尝试了解一些基本知识

使用SQL时为什么需要连接到服务器？
在我的非常狭隘的视野中，它只使用一些数据库，例如可以实现为数组（或任何在“后台”实现的数据库）。
例如，如果我想在计算机中设置一个表并对其执行一些操作，服务器有什么用途？为什么它不能“就在那里”

您所设想的（大致上）被称为进程内数据库，它们确实存在于SQL中。SQL Server被设置为供多个用户或应用程序使用，因此，将其作为一个中心服务器是有意义的，许多客户端可以连接到该服务器，以便共享相同的数据

---

如果您只想在本地处理数据，那么可以使用SQL Express LocalDB、SQLite和其他一些工具在应用程序中嵌入SQL引擎。

您可能将

SQL

语言与实现SQL的Microsoft产品

SQL Server

相混淆

SQL

本身有很多很多实现。其中许多实现不使用服务器。MS Access、SQLite和FileMaker是常见的SQL使用产品，它们依赖于文件共享而不是客户机-服务器设置来提供多用户访问。这些产品也可以在一台机器上使用，而无需共享文件

也有使用CSV文件存储的SQL实现，尽管这些实现不太常见

---

最后，许多客户机-服务器SQL产品提供了不需要服务器的相关、较小规模的实现。这些通常也使用文件共享来实现。

这取决于您需要什么。有些SQL实例（如SQLite3）是本地的，并且基于文件。他们没有服务器。大多数提供服务器是因为它们解决了问题

但让我们来说明为什么需要服务器。考虑一个微软Access应用程序，其中数据库是通过网络共享的文件。假设有5个人在使用同一个文件。他们每个人都在搜索一些东西，整个文件必须通过网络传递。假设一个人编辑一条记录。下次其他人进行搜索时，他们将不得不再次加载整个文件。如果文件很大，这将对性能造成巨大影响。这就是创建服务器的原因

服务器只接收SQL。服务器执行搜索或编辑，并仅返回已请求的数据。对于任何大小合理的数据库，性能改进都是巨大的

服务器的另一个好处是访问控制。使用服务器，您可以拥有多个帐户，并控制他们可以访问哪些数据库甚至表，以及允许他们执行哪些活动

---

简而言之，创建服务器是为了解决多个客户机使用单个数据库时出现的问题

我认为您感到困惑的原因是将“服务器”一词理解为一个单独的硬件盒太狭隘了

---

服务器不需要在单独的硬件上运行，甚至不需要在单独的虚拟环境中运行。它可能是同一台计算机上的另一个进程，甚至是进程中的一个库。它之所以成为服务器，是因为它能够接受和处理来自客户端的请求。服务器在何处实际运行并不重要：只要您遵循在客户端发起请求的协议，您就拥有了一台服务器。

您认为是什么解释了SQL命令并将其转换为实际执行的命令？什么决定了要使用什么索引？是什么强制约束、执行触发器和存储过程？如果您编写的实现采用SQL、通过网络传输命令并返回结果，那么无论底层实现如何，您都已经构建了一个服务器。也就是说，看看Linq。那么您将服务器定义为“在比文件更细粒度的级别上共享数据”的东西吗？不，我将服务器定义为我认为是标准定义的一个过程，它不同于客户端。一般来说，服务器是一个独立的工作站，但我确信我们都在同一个工作站（甚至是生产系统）上运行客户机和服务器的开发环境。这仍然不同于进程内库，甚至不同于SQL实现源直接编译到可执行文件中的情况。@Larry Lustig当你说文件共享时，你的意思是“客户端”在数据库上运行，这会消耗资源，因此需要服务器吗？正如noel的回答一样，需要一个共享文件系统，但不需要数据库服务器。共享文件系统可以位于单独的框中（在这种情况下，它将被称为文件服务器），或者其中一个工作站可以共享其文件系统（从技术上讲，仍然是文件服务器，但不是数据库服务器）。如果使用单词thread而不是process，同样的情况是否正确？例如，在一些Java项目中，假设我在一个名为“Data”的类中有一个名为“field”的字段，这是一个线程（实现Runnable），我试图从其他线程中更改“field”，这会被视为服务器吗？（假设“field”是公共的）。@achie您甚至不需要线程-一个像服务器一样使用的类可以在主线程上完成其工作。其效果与同步调用服务器相同。只要代码将类视为逻辑服务器，就可以将其视为程序的本地服务器，而不管它的实现是什么。不过，通常情况下，服务器确实意味着某种程度的分离——至少在某种程度上，当服务器停机时，应用程序保持运行。进程内服务器不满足这一要求。那么，操作系统和计算机内存会被视为服务器和数据库吗？因为很多进程都在试图访问它，但操作系统本身才是最重要的