Part VI: Access as an Enterprise Platform
1190
l (^) Partitioning and parallel processing: Physical splitting of tables into separate partitions,
including parallel processing on multiple partitions, or individual operations performed
on individual partitions. Table partitioning is particularly useful with very large tables
when only a portion of the data is likely to be queried at one time. Querying a small por-
tion of a table is called partition pruning.
Even though the Access Database Engine and Jet don’t support the advanced features in SQL
Server, Access supports truly sophisticated forms and report builders. And even though SQL
Server supports a rather nice reporting tool (SQL Server Reporting Services, or SSRS), the features
of SSRS pale in comparison to Access reports. And, as I’ve said, SQL Server has no user-interface
builder or design at all (other than database-management tools). SQL Server is entirely dependent
on other applications, such as Access, SharePoint, and Visual Studio, for providing end users with
interfaces for viewing and working with data.
A huge improvement of the Access Database Engine over the Jet database engine is that the Access
Database Engine has built-in integration with SharePoint Services. The Access Database Engine
handles all the complexity of communicating with SharePoint operating on a remote server located
across the Internet.
Cross-Reference
For more on SharePoint Services, see Chapter 33.
Web servers and application servers
On a most basic level, a Web server and an application server perform exactly the same function.
They both play a role as a processing and pooling funnel between application computers and back-
end server computers.
Figure 36.4 illustrates that the difference between the computers shown in Figure 36.1 and those
shown in Figure 36.4 is a difference of scale and scalability. In Figure 36.4, there is much more
interrogation and direct access to the database on the single-server computer. A single-server com-
puter is limited as to how much load it can manage without causing performance problems for its
users. Even if the server computer in Figure 36.4 is a large cluster of physical servers, it’s probably
doing too much work as a database server, a Web server, and a reporting server at the same time.
Overloading a database server can be prevented by using intermediary servers. In Figure 36.5, the
load on the central server has been distributed among dedicated Web, application, and database
servers. Although more expensive to initially install and configure, and more expensive to maintain
in the long term, a distributed system provides much higher performance overall. Each server in
Figure 36.5 is optimized for its particular task, and, as long as the loads directed to each server are
managed properly, users benefit from much better application performance.