Client/Server Architecture

Microsoft® SQL Server™ is designed to work effectively in a number of environments:

• As a two-tier or multitier client/server database system
• As a desktop database system

Client/Server Database Systems

Client/server systems are constructed so that the database can reside on a central computer, known as a server, and be shared among several users. Users access the server through a client or server application:

• In a two-tier client/server system, users run an application on their local computer, known as a client, that connects over a network to the server running SQL Server. The client application runs both business logic and the code to display output to the user, and is also known as a thick client.
• In a multitier client/server system, the client application logic is run in two locations:
  • The thin client is run on the user’s local computer and is focused on displaying results to the user.
  • The business logic is located in server applications running on a server. Thin clients request functions from the server application, which is itself a multithreaded application capable of working with many concurrent users. The server application is the one that opens connections to the database server and can be running on the same server as the database, or it can connect across the network to a separate server operating as a database server.

    This is a typical scenario for an Internet application. For example, a server application can run on a Microsoft Internet Information Services (IIS) and service thousands of thin clients running on the Internet or an intranet. The server application uses a pool of connections to communicate with a copy of SQL Server. SQL Server can be installed on the same computer as IIS, or it can be installed on a separate server in the network.

Having data stored and managed in a central location offers several advantages:

• Each data item is stored in a central location where all users can work with it.

  Separate copies of the item are not stored on each client, which eliminates problems with users having to ensure they are all working with the same information.

• Business and security rules can be defined one time on the server and enforced equally among all users.

  This can be done in a database through the use of constraints, stored procedures, and triggers. It can also be done in a server application.

• A relational database server optimizes network traffic by returning only the data an application needs.

  For example, if an application working with a file server needs to display a list of the names of sales representatives in Oregon, it must retrieve the entire employee file. If the application is working with a relational database server, it sends this command:

  SELECT first_name, last_name

  FROM employees

  WHERE emp_title = 'Sales Representative'

    AND emp_state = 'OR'

    

  The relational database sends back only the names of the sales representatives in Oregon, not all of the information about all employees.

• Hardware costs can be minimized.

  Because the data is not stored on each client, clients do not have to dedicate disk space to storing data. The clients also do not need the processing capacity to manage data locally, and the server does not need to dedicate processing power to displaying data.

  The server can be configured to optimize the disk I/O capacities needed to retrieve data, and clients can be configured to optimize the formatting and display of data retrieved from the server.

  The server can be stored in a relatively secure location and equipped with devices such as an Uninterruptable Power Supply (UPS) more economically than fully protecting each client.

• Maintenance tasks such as backing up and restoring data are simplified because they can focus on the central server.

In large client/server systems, thousands of users may be connected to a SQL Server installation at the same time. SQL Server has full protection for these environments, with safeguards that prevent problems such as having multiple users trying to update the same piece of data at the same time. SQL Server also allocates the available resources effectively, such as memory, network bandwidth, and disk I/O, among the multiple users.

SQL Server applications can run on the same computer as SQL Server. The application connects to SQL Server using Windows Interprocess Communications (IPC) components, such as shared memory, instead of a network. This allows SQL Server to be used on small systems where an application needs to store its data locally.

Desktop Database Systems

While SQL Server works effectively as a server, it can also be used in applications that need stand-alone databases stored locally on the client. SQL Server can configure itself dynamically to run efficiently with the resources available on a client, without the need to dedicate a database administrator to each client. Application vendors can also embed SQL Server as the data storage component of their applications.

When clients use local SQL Server databases, one copy of the SQL Server database engine runs on the client and manages all the SQL Server databases on the client. Applications connect to the database engine in much the same way they connect across the network to a database engine running on a remote server.