山东理工大学
英-中文翻译材料
英文题目： Brief Introduction 中文题目：
学 院： 计算机科学与技术
专 业： 软件工程
学生姓名： 米东文
指导教师： 刘秋香
二O一五年六月
英文资料
Brief Introduction to .NET
The .NET Framework
The .NET Framework is a multi-language environment for building, deploying, and running XML Web services and applications. It consists of three main parts:
? Common Language Runtime Despite its name, the runtime actually has a role in
both a component's runtime and development time experiences. While the component is running, the runtime is responsible for managing memory allocation, starting up and stopping threads and processes, and enforcing security policy, as well as satisfying any dependencies that the component might have on other components. At development time, the runtime's role changes slightly; because it automates so much (for example, memory management), the runtime makes the developer's experience very simple, especially when compared to COM as it is today. In particular, features such as reflection dramatically reduce the amount of code a developer must write in order to turn business logic into a reusable component.
? Unified programming classes The framework provides developers with a unified,
object-oriented, hierarchical, and extensible set of class libraries (APIs). Currently, C++ developers use the Microsoft Foundation Classes and Java developers use the Windows Foundation Classes. The framework unifies these disparate models and gives Visual Basic and JScript programmers’ access to class libraries as well. By creating a common set of APIs across all programming languages, the common language runtime enables cross-language inheritance, error handling, and debugging. All programming languages, from JScript to C++, have similar access to the framework and developers are free to choose the language that they want to use.
? ASP.NET ASP.NET builds on the programming classes of the .NET Framework,
providing a Web application model with a set of controls and infrastructure that make it simple to build ASP Web applications. ASP.NET includes a set of controls that encapsulate common HTML user interface elements, such as text boxes and drop-down menus. These controls run on the Web server, however, and push their user interface as HTML to the browser. On the server, the controls expose an object-oriented programming model that brings the richness of object-oriented programming to the Web developer. ASP.NET also provides infrastructure services, such as session state management and process recycling, which further reduce the
- 1 -
英文资料
amount of code a developer must write and increase application reliability. In addition, ASP.NET uses these same concepts to enable developers to deliver software as a service. Using XML Web services features, ASP.NET developers can write their business logic and use the ASP.NET infrastructure to deliver that service via SOAP. DATA CONNECTION
Introduction
The top of the stack is the API or object library layer. Applications connect to Microsoft? SQL Server through either API functions or interfaces exposed by an object library. Examples of APIs used to access SQL Server include ODBC and DB-Library. Examples of object libraries used to access SQL Server include OLE DB, ADO, and ADO.NET. Because ADO ultimately uses OLE DB to communicate with the server, there are really just two object libraries commonly used by Windows applications to communicate with SQL Server: OLE DB and ADO.NET. Connecting through ADO or ADO.NET is certainly more common than doing so over ODBC (although SQL Server's Query Analyzer and Enterprise Manager Still connect over ODBC), so I'll discuss the client-side of SQL Server's connection architecture in terms of ADO/OLE DB and ADO.NET. Most apps these days get to SQL Server by way of an object library rather than ODBC or something similar.
ADO and OLE DB
OLE DB clients (also known as consumers) communicate with servers and other back-ends by means of a client-side provider. This provider is a set of one or more COM components that translate application requests into network interposes communication (IPC) requests. In the case of SQL Server, the OLE DB provider that is most commonly used is SQLOLEDB, the Microsoft-provided OLE DB provider for SQL Server. SQLOLEDB comes with SQL Server and is installed as part of the Microsoft Data Access Components (MDAC) stack.
Applications that communicate with SQL Server using ADO do so by first establishing a connection to the server using a Connection object. ADO's Connection
- 2 -
英文资料
object accepts a connection string that specifies the OLE DB provider to be used as well as the parameters to pass to it. You'll see "SQLOLEDB" in this string if an app is connecting to SQL Server using the SQLOLEDB provider.
It's also possible for an ADO application to connect over ODBC to SQL Server. To do this, the app uses the OLE DB provider for ODBC and specifies an ODBC data source that references the target SQL Server in its connection string. In this scenario, the application communicates with OLE DB, and the OLE DB provider for ODBC makes the appropriate ODBC API calls to talk to SQL Server.
ADO.NET
ADO.NET applications typically connect to SQL Server using the .NET Framework Data Provider for SQL Server. This native provider allows ADO.NET objects to communicate directly with SQL Server. Typically, an application uses a SqlConnection object to establish a connection, and then uses a SqlCommand object to send commands to the server and receive results back from it. The SqlDataAdapter and SqlDataReader classes are typically used in conjunction with SqlCommand to interact with SQL Server from managed code applications.
By making use of the OleDbConnection class, ADO.NET applications can also use the SQLOLEDB OLE DB provider to interact with SQL Server. And they can access SQL Server by way of ODBC through the OdbcConnection class. So, from managed code alone, you have three distinct ways of accessing SQL Server from an application. This is good to know from a troubleshooting standpoint because it can help you isolate connection-related problems you encounter to a particular data access layer or library.
Client-Side Net-Libraries
The next layer down in the stack is the Net-Library. A Net-Library provides the conduit between the API or object library an application uses to communicate with SQL Server and the networking protocols used to exchange data with the network. SQL Server provides Net-Libraries for all major networking protocols. These libraries transparently handle sending requests from the client to the SQL Server and returning
- 3 -
英文资料
the server's responses to the client. You can configure which Net-Libraries are available on a particular client using SQL Server's Client Network Utility. Supported client-side protocols include TCP/IP, Named Pipes, Multiprotocol (RPC), and a few others.
One Net-Library that's worth special mention here is the shared memory Net-Library. As the name suggests, this Net-Library uses Windows' shared memory facility to communicate between a SQL Server client and server. Naturally, this means that the client and server must reside on the same physical machine.
Because it is able to bypass the physical network stack, the shared memory Net-Library can be considerably faster than other Net-Libraries. Access to the shared memory region is protected by synchronization objects, so the speed of the communication between the client and server is constrained mainly by Windows' ability to signal and unsigned kernel objects and processes' ability to copy data to and from the shared memory region.
You can indicate that the shared memory Net-Library should be used by specifying either a period or (local) as your machine name when connecting. You can also prefix your machine\instance name with loc: when connecting to indicate that you want to use the shared memory Net-Library.
Understand that, even when connecting to a SQL Server on the same machine, the shared memory Net-Library is not necessarily your best connection option. The directness of the connection between the client and server can limit its scalability in some situations. As with other elements in an application's overall architecture, you should always thoroughly test a given technology solution before assuming that it scales well or is faster than alternate approaches.
Connections
When a client connects, SQL Server's user mode scheduler (UMS) component assigns it to a particular scheduler. At startup, SQL Server creates a separate UMS scheduler for each CPU on the system. As clients connect to the server, they are assigned to the scheduler with the fewest number of connections. Once connected, a
- 4 -
英文资料
client never changes schedulers—it will remain on its assigned scheduler until it disconnects.
This has important implications for applications that establish multiple connections to the server. If an application is poorly designed or does not evenly distribute work across its connections, it's possible for the app to cause needless contention for CPU resources between some of its connections, while others remain virtually idle.
Say, for example, that at application establishes four connections to SQL Server that is running on a machine with two processors and that connections 1 and 3 end up on processor 0, while connections 2 and 4 end up on processor 1. If the lion's share of the app's work is carried out over connections 1 and 3, they will contend for CPU 0 while CPU 1 might remain virtually idle. In this situation, there's nothing the app can do but disconnect/reconnect some of its connections and hope that connections 1 and 3 end up on different CPUs (there's no way to specify processor affinity when connecting) or redistribute its workload across its connections such that they are more balanced. The latter is, of course, far preferable to the former. Connection Memory
SQL Server sets aside three packet buffers for every connection made from a client. Each buffer is sized according to the default network packet size specified by the sp_configure stored procedure. If the default network packet size is less than 8KB, the memory for these packets comes from SQL Server's buffer pool. If it's 8KB or larger, the memory is allocated from SQL Server's MemToLeave region.
It's worth noting that the default network packet size for the .NET Framework Data Provider for SQL Server is 8KB, so the buffers associated with managed code client connections typically come from SQL Server's MemToLeave region. This contrasts with classic ADO applications, where the default packet size is 4KB, and the buffers are allocated form the SQL Server buffer pool.
- 5 -
英文资料
Events
Once connected, client requests typically fall into one of two broad categories: language events and remote procedure calls. Although there are certainly others, most requests from a SQL Server client to a server consist of one of these two types. A language event is a batch of T-SQL sent from the client to the server. For example, if you call the Execute method of an ADO Command object whose CommandText property is set to a T-SQL query and whose CommandType property is set to adCmdText, the query is submitted to the server as a language event. Likewise, if you set CommandType to adCmdTable and call the Execute method, ADO will generate an internal query that selects all the columns in the table identified by the CommandText property and submit it to the server as a language event. On the other hand, if you set CommandType to adStoredProc, calling Execute will cause ADO to submit a remote procedure call request to the server to execute the stored procedure listed in the CommandText property.
Why do you care about whether you're submitting requests to the server as language events or RPCs? You care because RPCs, generally speaking, perform better, especially when you're repeatedly calling the same query with different filter values. Although SQL Server can auto-parameterize plain language event requests, its ability to do so is pretty limited. It will not attempt to auto-parameterize certain types of queries at all. This can cause different executions of what is essentially the same query to incur the cost of plan compilation on the server simply because they filter on different values. Quite often, this is not what you want—you want to compile a new plan for the first execution of a query, then reuse the plan for subsequent executions that happen to feature different parameters.
An RPC, on the other hand, encourages plan reuse by explicitly parameter zing a query rather than relying on the server to do it. A single plan is generated for the first execution of the procedure, and subsequent executions automatically reuse it, even if they supply different values for the parameters. Calling a stored procedure using an RPC versus doing so through a language event not only saves the execution time and CPU resources required for plan compilation, it also makes better use of
- 6 -
英文资料
SQL Server's memory resources because it avoids wasting memory on redundant execution plans.
This is the same reason that sp_executesql is generally preferred to EXEC() when executing dynamic T-SQL. Sp_executesql works by creating a stored procedure using the specified query, then calling it using the supplied parameters. Unlike EXEC(), sp_executesql provides a mechanism that allows you to parameterize dynamic T-SQL and encourage plan reuse. A dynamic query that is executed using sp_executesql has a much better chance of avoiding unnecessary compilation and resource costs than one ran using EXEC().
TDS
RPCs, language events, and other types of requests sent from a client to SQL Server are formatted into a SQL Server-specific data format known as Tabular Data Stream (TDS). TDS is the "language" spoken between SQL Server clients and servers. Its exact format is no longer documented, but a client must speak TDS if it wishes to communicate with SQL Server.
Currently, SQL Server supports three versions of TDS: TDS 8.0 (for SQL 2000 clients), TDS 7.0 (for SQL Server 7.0 clients), and TDS 4.2 (for SQL Server 4.2, 6.0, and 6.5 clients). The only version that completely supports all SQL Server 2000 features is TDS 8.0. The others are maintained for backward compatibility.
Server-Side Net-Libraries
On the server side, client requests are initially received by listeners SQL Server sets up to listen on particular networking protocols. These listeners consist of networking libraries on the server and the server-side Net-Libraries that provide a conduit between them and the server. You can configure the protocols on which the server listens using the Server Network Utility. Except when dealing with clusters, SQL Servers support the same range of networking protocols as is supported by clients. For clustered SQL Servers, only TCP/IP and Named Pipes are available.
- 7 -
英文资料
SQL Server sets up one thread per networking protocol on which it listens for client requests, and uses Windows' I/O completion port mechanism to wait for and process requests efficiently. As TDS packets are received from the network, the Net-Library listener reassembles them into their original client requests and passes them on to SQL Server's command-processing layer, Open Data Services (ODS).
Returning Results to the Client
When the server is ready to return results for a particular client request, it uses the same network stack over which the request was initially received. It sends results over the server-side Net-Library to the appropriate networking protocol, and these, in turn, are sent back across the network to the client in TDS format.
On the client-side, the TDS packets received from the server are reassembled from the IPC layer by the client-side Net-Library, and then forwarded on to the API or object library that initiated the request.
Putting It All Together
Despite all the pieces involved, the roundtrip between a SQL Server client and server can be quite fast—sub-second response time is not unusual at all, especially when working with the shared memory Net-Library. There are several data points here that are worth keeping in mind as you build and tune your own SQL Server client applications:
? If your app runs on the same machine as your SQL Server, consider using the
shared memory Net-Library if you aren't already. Shared memory Net-Library-based connections are often considerably faster than other types of connections. Keep in mind what I said earlier, though: always thoroughly test a solution and compare it with viable alternatives before assuming that it is inherently better or faster. The proof is in the pudding.
? Because a client is assigned to a particular UMS scheduler when it first
connects and will not leave that scheduler until it disconnects, it's important to ensure that an application's workload is balanced across the connections it
- 8 -
英文资料
establishes to the server. Unbalanced workloads can cause unnecessary CPU contention and suboptimal resource usage.
? The default network packet size you configure on the server and that clients
specify when connecting directly affects how much memory they require on the server and the pool from which it is allocated. Keep this in mind as you configure servers for scalability and speed. Also keep in mind that, by default, ADO.NET apps will have a larger network packet size than ADO apps. ? Generally speaking, you should prefer RPCs to language events when sending
requests to the server. Set the appropriate properties in the ADO or ADO.NET objects you're using to facilitate this.
? When executing dynamic T-SQL, use sp_executesql rather than EXEC() when
possible. About the only time this isn't possible is when using EXEC()'s ability to concatenate query fragments into dynamic query strings that exceed what can be stored in a single local variable (a rare situation).
? When you run into client-side problems that you suspect may have to do with
the object library or API you're using to reach the server, one troubleshooting technique you can use is to change the client-side mechanism you're using so that you can isolate the problem to a particular component. For example, let's say that you upgrade MDAC and begin seeing 17805 errors in your SQL Server error log indicating that malformed TDS packets are arriving from a client-side ADO application. You might try switching the app to use the OLE DB provider for ODBC, if you can do so without much trouble, to see whether the problem is related to the SQLOLEDB provider in some way. Conversely, if your ADO-based app has been connecting over ODBC, you might switch to SQLOLEDB to see if that remedies the problem or at least helps you narrow the scope.
? Along these same lines, it sometimes makes sense to change out the
Net-Library you're using when troubleshooting connection-related problems. If you're using TCP/IP, perhaps Named Pipes would be worth trying. For example, if you're running into an issue with your DHCP server and don't have a valid IP address, you won't be able to connect to SQL Server using TCP/IP.
- 9 -
英文资料
By switching to Named Pipes, you can quickly isolate the problem to something specific to TCP/IP. On the other hand, if you switch Net Libraries and still have the same problem, you can probably rule out Net-Library-specific issues. Perhaps the server is down or a piece of the network infrastructure between you and the server is not functioning properly. If nothing else, being able to easily change the Net-Library an app uses without having to change the app itself gives you a tool for helping isolate problems. Even if a particular Net-Library isn't viable for you in the long term, temporarily switching a client to use it can help narrow down where a connection-related issue resides.
Introduction to information management system of the hotel
Purpose of this project are: universal access to computer technology, the traditional hotel management technology does not suit the needs of the contemporary development of hotel and guesthouse accommodation, hotel management to keep the guests one of the major factors. Hotel business links related to the work of more broad, the hotel is no longer only the traditional accommodation and settlement, but contains a wider range of services. As a service industry, from the guests scheduled to stay at the hotel registration until you check out, if you can provide fast and convenient service to guests, you will give guests a better feeling, so that you can enhance the rate of second glance of the hotel. Hotel information management system is in such demand.
This project is mainly to solve daily basic requirements of hotels involved in the management of information, the goal is to make the administrator a convenient, speedy and efficient room on the Web site management, reservations, check out business. This site includes basic information management staff, rooms basic information management, reservation management, room unsubscribe management, sales management, and other important modules.
- 10 -
中文翻译
.NET简介
.NET 框架
.NET Framework 是用于生成、部署和运行 XML Web services 和应用程序的多语言环境。它由三个主要部分组成：
? 公共语言运行库 运行库实际上在组件的运行时和开发时操作中都起到
很大的作用，尽管名称中没有体现这个意思。在组件运行时，运行库除了负责满足此组件在其他组件上可能具有的依赖项外，还负责管理内存分配、启动和停止线程和进程，以及强制执行安全策略。在开发时，运行库的作用稍有变化；由于做了大量的自动处理工作（如内存管理），运行库使开发人员的操作非常简单，尤其是与今天的 COM 相比。特别是反射等功能显著减少了开发人员为将业务逻辑转变为可重用组件而必须编写的代码量。
? 统一编程类 该框架为开发人员提供了统一的、面向对象的、分层的和
可扩展的类库集 (API)。目前，C++ 开发人员使用 Microsoft 基础类，而 Java 开发人员使用 Windows 基础类。框架统一了这些完全不同的模型并且为 Visual Basic 和 JScript 程序员同样提供了对类库的访问。通过创建跨所有编程语言的公共 API 集，公共语言运行库使得跨语言继承、错误处理和调试成为可能。从 JScript 到 C++ 的所有编程语言具有对框架的相似访问，开发人员可以自由选择它们要使用的语言。
? ASP.NET ASP.NET 建立在 .NET Framework 的编程类之上，它提供了一
个 Web 应用程序模型，并且包含使生成 ASP Web 应用程序变得简单的控件集和结构。ASP.NET 包含封装公共 HTML 用户界面元素（如文本框和下拉菜单）的控件集。但这些控件在 Web 服务器上运行，并以 HTML 的形式将它们的用户界面推送到浏览器。在服务器上，这些控件公开一个面向对象的编程模型，为 Web 开发人员提供了面向对象的编程的丰富性。ASP.NET 还提供结构服务（如会话状态管理和进程回收），进一步减少了开发人员必须编写的代码量并提高了应用程序的可靠性。另外，ASP.NET 使用这些同样的概念使开发人员能够以服务的形式交付软件。使用 XML Web services 功能，ASP.NET 开发人员可以编写自己的业务逻辑并使用 ASP.NET 结构通过 SOAP 交付该服务。
- 1 -
中文翻译
数据连接
引言
该堆栈的顶部是 API 或对象库层。应用程序通过对象库公开的 API 函数或接口连接到 Microsoft? SQL Server。用于访问 SQL Server 的 API 示例包括 ODBC 和 DB-Library。用于访问 SQL Server 的对象库示例包括 OLE DB、ADO 和 ADO.NET。由于 ADO 最终使用 OLE DB 与服务器通信，因此 Windows 应用程序在与 SQL Server 通信时实际上只使用两个常用的对象库，即 OLE DB 和 ADO.NET。由于通过 ADO 或 ADO.NET 进行连接通常比通过 ODBC 进行连接更普遍（但 SQL Server 的查询分析器和企业管理器仍通过 ODBC 进行连接），因此本文将从 ADO/OLE DB 和 ADO.NET 的角度介绍 SQL Server 连接体系结构的客户端。如今，大多数应用程序均通过对象库（而非 ODBC 或类似 API）连接到 SQL Server。
ADO 和 OLE DB
OLE DB 客户端（也称作使用者）通过客户端提供程序与服务器以及其他后端程序进行通信。此提供程序是一组 COM 组件（一个或多个），用于将应用程序请求转换为网络进程间通信 (IPC) 请求。在使用 SQL Server 的情况下，最常用的 OLE DB 提供程序是 SQLOLEDB，它是 Microsoft 为 SQL Server 提供的 OLE DB 提供程序。SQLOLEDB 随附于 SQL Server 中，并作为 Microsoft 数据访问组件 (MDAC) 库的一部分安装。
为了使用 ADO 与 SQL Server 进行通信，应用程序首先使用 Connection 对象建立与服务器的连接。ADO 的 Connection 对象接受一个连接字符串，该字符串指定要使用的 OLE DB 提供程序以及传递给它的参数。如果应用程序使用 SQLOLEDB 提供程序连接到 SQL Server，则该字符串中将显示“SQLOLEDB”。
ADO 应用程序还可以通过 ODBC 连接到 SQL Server。为此，应用程序将使用适用于 ODBC 的 OLE DB 提供程序，并指定在其连接字符串中引用目标 SQL Server 的 ODBC 数据源。这种情况下，应用程序与 OLE DB 进行通信，同时 ODBC 的 OLE DB 提供程序调用相应的 ODBC API，以便与 SQL Server 进行会话。 ADO.NET
- 2 -
中文翻译
ADO.NET 应用程序通常使用 .NET Framework Data Provider for SQL Server 连接到 SQL Server。该本机提供程序使 ADO.NET 对象能够与 SQL Server 直接进行通信。通常，应用程序使用 SqlConnection 对象建立连接，然后使用 SqlCommand 对象向服务器发送命令，并接收服务器返回的结果。SqlDataAdapter 和 SqlDataReader 类通常与 SqlCommand 一起使用，以便通过托管的代码应用程序与 SQL Server 进行交互。
通过 OleDbConnection 类，ADO.NET 应用程序还可以使用 SQLOLEDB OLE DB 提供程序与 SQL Server 进行交互。此外，它们可以通过 OdbcConnection 类使用 ODBC 访问 SQL Server。因此，仅通过托管代码，您就有三种不同的方法从应用程序访问 SQL Server。从故障排除的角度而言，了解这些方法是非常有用的，因为它可以帮助您将遇到的与连接相关的问题归结到特定的数据访问层或库。
客户端 Net-Library
该堆栈中的下一层是 Net-Library。Net-Library 在 API 或对象库（应用程序使用它与 SQL Server 进行通信）与网络协议（用于与网络交换数据）之间提供了一个通道。SQL Server 为所有主要的网络协议提供了 Net-Library。这些库以透明方式将客户端发出的请求发送到 SQL Server，并将服务器发出的响应返回给客户端。可以使用 SQL Server 的客户端网络实用程序配置适用于特定客户端的 Net-Library。支持的客户端协议包括 TCP/IP、命名管道、多协议 (RPC) 和其他一些协议。
尤其值得一提的 Net-Library 是共享内存 Net-Library。顾名思义，该 Net-Library 使用 Windows 的共享内存功能在 SQL Server 客户端与服务器之间进行通信。显然，这意味着客户端与服务器必须位于同一台物理计算机上。 由于它能够绕过物理网络堆栈，因此共享内存 Net-Library 要比其他 Net-Library 快得多。对共享内存区域的访问受到同步对象的保护，因此客户端与服务器之间的通信速度主要受限于 Windows 对内核对象进行调度的能力，以及进程与共享内存区域之间进行数据复制的能力。
可以在连接时将某个时间段或（本地）指定为您的计算机名，来指示使用共享内存 Net-Library。也可以在连接时为计算机\实例名加上前缀 lpc:，来指示要使用共享内存 Net-Library。
- 3 -
中文翻译
注意，即使连接到同一台计算机上的 SQL Server，共享内存 Net-Library 也未必就是最佳的连接选项。在某些情况下，客户端与服务器之间的直接连接可能限制它的扩展性。与应用程序整体体系结构中的其他元素一样，应始终对给定技术解决方案进行全面的测试，然后才能判断它是否有良好的扩展性以及是否比其他方法更快。
连接
客户端进行连接时，SQL Server 的用户模式计划程序 (UMS) 组件将它指定给特定的计划程序。启动时，SQL Server 为系统上的每个 CPU 创建一个单独的 UMS 计划程序。当客户端连接到服务器时，这些客户端将指定给具有最少连接数的计划程序。连接后，客户端将不会更换计划程序 - 它将始终受到指定计划程序的控制，直到连接断开。
这对与服务器建立多个连接的应用程序很重要。如果应用程序性能较差，或无法在它的多个连接上平均分配工作，则在该应用程序的某些连接之间可能造成不必要的 CPU 资源争用，而其他连接实际上却处于空闲状态。
例如，应用程序与双处理器计算机上运行的 SQL Server 建立了四个连接，连接 1 和 3 隶属于处理器 0，连接 2 和 4 隶属于处理器 1。如果应用程序的大部分工作通过连接 1 和 3 执行，则这两个连接将争用 CPU 0，而 CPU 1 实际上可能仍处于空闲状态。这种情况下，应用程序只能断开某些连接或重新连接某些连接，并希望连接 1 和 3 隶属于不同的 CPU （连接时无法指定处理器隶属关系），或在它的连接上重新分配工作负荷，以便每个连接的工作负荷更加均衡。当然，后一种情况要远好于前一种情况。
连接内存
SQL Server 为客户端请求的每个连接保留三个数据包缓冲区。每个缓冲区的大小取决于 sp_configure 存储过程指定的默认网络数据包大小。如果默认网络数据包大小小于 8 KB，则这些数据包的内存将由 SQL Server 的缓冲池提供。否则，该内存将由 SQL Server 的 MemToLeave 区域分配。
值得一提的是，.NET Framework Data Provider for SQL Server 的默认网络数据包大小为 8KB，因此，与托管代码客户端连接关联的缓冲区通常由 SQL Server 的 MemToLeave 区域提供。而典型的 ADO 应用程序却不同，它们的默认数据包大小为 4 KB，因此缓冲区将由 SQL Server 缓冲池分配。
- 4 -
中文翻译
事件
连接后的客户端请求通常分为两种广泛类别：语言事件和远程过程调用。尽管还存在其他类别，但大多数由 SQL Server 客户端发送到服务器的请求由以下两种类型之一构成：语言事件是从客户端发送到服务器的 一组 T-SQL。例如，如果调用 ADO Command 对象（其 CommandText 属性设置为 T-SQL 查询，CommandType 属性设置为 adCmdText）的 Execute 方法，则查询将作为语言事件提交给服务器。同样，如果将 CommandType 设置为 adCmdTable 并调用 Execute 方法，则 ADO 将生成一个内部查询（它将选择 CommandText 属性标识的表中的所有列），并将它作为语言事件提交给服务器。另一方面，如果将 CommandType 设置为 adStoredProc，则调用 Execute 将使 ADO 向服务器提交一个远程过程调用请求，以执行 CommandText 属性中列出的存储过程。
为何要关心将请求作为语言事件还是作为 RPC 提交给服务器呢？通常，这是因为 RPC 的功能更为出色，特别是在重复调用具有不同筛选值的同一查询时。尽管 SQL Server 可以自动将普通的语言事件请求参数化，但这种能力非常有限。它从不尝试自动将某些类型的查询参数化。这可能会导致基本相同的查询产生不同的执行，从而只因为这些不同的执行提供不同的值，而导致在服务器上白白浪费计划编译的成本。这通常不是您所希望的结果 - 您希望针对查询的第一次执行编译一个新的计划，然后将该计划重复用于具有不同参数的执行。
而 RPC 则通过显式参数化查询（而不是依赖服务器参数化查询）来支持计划重复使用。为过程的第一次执行生成一个计划后，随后的执行将自动重复使用该计划，即使它们提供的参数值不同。与通过语言事件调用存储过程相比，使用 RPC 调用存储过程不仅节省了计划编译所需的执行时间和 CPU 资源，还增强了 SQL Server 内存资源的利用率，因为它避免了冗余执行计划所浪费的内存。
在执行动态 T-SQL 时，通常首选 sp_executesql 而不是 EXEC() 也出于同样的原因。Sp_executesql 的工作方式是：使用指定的查询创建一个存储过程，然后使用提供的参数调用它。与 EXEC() 不同，sp_executesql 提供了一个允许您参数化动态 T-SQL 并支持计划重复使用的机制。使用 sp_executesql 执行的动态查询比使用 EXEC() 的查询能够在更大程度上避免不必要的编译和资源消耗。
TDS
- 5 -
中文翻译
从客户端发送到 SQL Server 的 RPC、语言事件和其他类型的请求被格式化为称作表格数据流 (TDS) 的 SQL Server 特定数据格式。TDS 是 SQL Server 客户端和服务器之间使用的“语言”。对于它的确切格式将不作介绍，但是，如果客户端要与 SQL Server 进行通信，就必须使用 TDS。
目前，SQL Server 支持三种版本的 TDS：TDS 8.0（适用于 SQL 2000 客户端）、TDS 7.0（适用于 SQL Server 7.0 客户端）和 TDS 4.2（适用于 SQL Server
4.2、6.0 和 6.5 客户端）。完全支持所有 SQL Server 2000 功能的版本只有 TDS 8.0。其他版本保持向后兼容。
服务器端 Net-Library
在服务器端，客户端请求最初由 SQL Server 为侦听特定网络协议而建立的侦听器接收。这些侦听器由服务器上的网络库以及服务器端的 Net-Library（在它们与服务器之间提供管道）构成。您可以使用 SQL Server 网络实用程序配置服务器侦听的协议。SQL Server 与客户端支持同样范围的网络协议（处理群集的情况除外）。对于群集化的 SQL Server，只有 TCP/IP 和命名管道可用。
SQL Server 为侦听客户端请求所使用的每个网络协议设置一个线程，并使用 Windows 的 I/O 完成端口机制等待和有效处理请求。从网络接收到 TDS 数据包时，Net-Library 侦听器将其重新汇编为它们的原始客户端请求，并将这些请求传递到 SQL Server 的命令处理层，即开放式数据服务 (ODS)。
将结果返回到客户端
服务器在准备将特定客户端请求的结果返回时，将使用最初接收请求时所用的网络堆栈。它通过服务器端 Net-Library 将结果发送到相应的网络协议，随后这些结果将通过网络以 TDS 格式返回到客户端。
在客户端上，客户端 Net-Library 将从服务器接收的 TDS 数据包从 IPC 层重新汇编，并将其继续转发到初始化该请求的 API 或对象库。
小结
尽管涉及了所有组件，但 SQL Server 客户端与服务器之间的往返过程却相当快 - 特别是在使用内存 Net-Library 时，亚秒响应时间非常普遍。构建和调整您自己的 SQL Server 客户端应用程序时，以下几个与数据相关的问题值得注意：
- 6 -
中文翻译
? 如果应用程序与 SQL Server 运行在同一台计算机上，则建议您使用共享
内存 Net-Library（如果尚未使用它）。基于共享内存 Net-Library 的连接通常比其他类型的连接快很多。在注意上述内容的同时，还应：始终全面测试解决方案并将它与其他可行方案进行对比，这样才能判断它是否确实更好或更快。事实胜于雄辩。
? 由于客户端在第一次连接时将指定给特定的 UMS 计划程序，并只有在断
开连接后，才会摆脱该计划程序的控制，因此确保在应用程序与服务器建立的连接上均衡分配工作负荷非常重要。工作负荷不均衡可导致不必要的 CPU 争用并降低资源使用率。
? 在服务器上配置的默认网络数据包大小以及客户端在连接时指定的网络
数据包大小将直接影响它们在服务器上所需的内存量和分配内存的池。对服务器进行扩展性和速度配置时，应记住这一点。还应记住，默认情况下，ADO.NET 应用程序的网络数据包大小比 ADO 应用程序的更大。 ? 通常，在向服务器发送请求时，应首选 RPC 而非语言事件。为此，应在
使用的 ADO 或 ADO.NET 对象中设置相应的属性。
? 执行动态 T-SQL 时，应在可能的情况下使用 sp_executesql 代替
EXEC()。唯一例外的情况是，当使用 EXEC() 的功能将查询片断连接而成的动态查询字符串的大小超过单个本地变量的存储大小时（这种情况非常少见）。
? 当遇到客户端问题，并且怀疑它可能和连接服务器时所用的对象库或 API
有关时，可以使用的一个故障排除技巧就是更改所用的客户端机制，这样可以将问题归结为特定的组件。例如，假设您升级 MDAC 并开始在 SQL Server 错误日志中看到 17805 错误，这表明客户端 ADO 应用程序发送的 TDS 数据包的格式不正确。您可能尝试让应用程序转为使用 ODBC 的 OLE DB 提供程序，如果您可以较为容易地做到这一点，应看看该问题是否与 SQLOLEDB 提供程序有一定的关系。相反，如果基于 ADO 的应用程序一直通过 ODBC 进行连接，则可以切换到 SQLOLEDB，看看这是否能解决问题，或至少帮助您缩小问题的范围。
? 同样，在对连接问题进行故障排除时，更改正在使用的 Net-Library 有
时会有所帮助。如果使用 TCP/IP，命名管道也许值得一试。例如，如果 DHCP 服务器出现问题，并且没有有效的 IP 地址，则您将无法使用 TCP/IP 连接到 SQL Server。通过切换到命名管道，可以快速地将问题归结为 TCP/IP 特定的因素上。另一方面，如果在切换 Net Library 后仍
- 7 -
中文翻译
存在同样的问题，则可以排除 Net-Library 方面的问题。问题的原因可能是服务器已关闭，或在您与服务器之间的某处网络基础设施无法正常工作。最后，还可以容易地更改应用程序使用的 Net-Library，而不必更改应用程序本身，这样就为您提供一个帮助缩小问题范围的工具。尽管从长远角度而言，使用某一特定 Net-Library 并不可行，但让客户端临时使用它可以帮助您缩小连接相关问题的范围。
该旅馆信息管理系统的介绍
本课题的目的是：随着计算机技术的普及，传统的旅馆管理技术已不能适应当代旅馆业发展的需要，旅馆管理成了留住客人的一个重大因素。旅馆业务的工作环节涉及的面也更加广泛，旅馆不再只有传统的住宿和结算业务，而是包含了更加广泛的服务内容。作为一个服务性的行业，从客人预定旅馆到入住登记直到退房，如果能够给客人提供快捷方便的服务，则会给客人留一种美好的感觉，从而可以提升旅馆的回头率。旅馆信息管理系统正是在这种需求下产生的。
本课题主要是解决日常旅馆信息管理中所涉及到的基本要求，目标是使管理员方便、快捷、高效的在网站上进行房间管理、订房、退房等业务。本网站主要包括员工基本信息管理、客房基本信息管理、预订管理、客房退订管理、营业额管理等重要模块。
- 8 -