Hi Tasha,
Sometimes this topic has a tendency to get a bit confusing, so let me try it this wayâ¦
The terms âfront-endâ and âback-endâ came into vogue with the emergence of the client/server architecture. In their original usage, âclientâ and âfront-endâ meant the same thing, and âserverâ and âback-endâ meant the same thing. Client or front-end referred to the actual machine (typically a smart PC, as opposed to a dumb terminal) that shared application processing with a server or backend machine(typically a PC or mainframe functioning as a database server). The terms client or front-end and server or backend are also used by folks to refer to the application components that run on the respective machines.
So if Iâm using a true client/server architecture (say, for example, an Access .mdb application using tables linked to SQL Sever via an ODBC connection â which I think is the setup you were asking about earlier), both Access and the workstation its running on can be referred to as the client or front-end and SQL Server (the database server) and the physical server machine its running on can be referred to as the server or backend.
So far so good. They mean the same thing, in a client/server architecture.
Confusion arises, however, from the fact that the data object file created by the Access Database Splitter is referred to as a âback-end databaseâ. This often suggests to folks, that what the Database Splitter creates is an application that involves a client/server architecture (a front-end application file and a back-end database server file that shares the data processing workload), when actually that isnât the case. The application created by the Database Splitter uses a shared-file architecture. The back-end file is merely a data store for native Jet tables. All of the data processing occurs on the front-end. So the âback-end databaseâ created by the Database Splitter isnât a true back-end, as the term is used in client/server nomenclature. Its simply a shared-file. Thatâs all.
So who cares? The important point to take home here, semantics aside, is understanding what happens when a front-end .mdb queries a âback-endâ shared-file in a shared-file architecture, and what happens when a front-end .mdb queries a database server in a client/server architecture.
Shared-file âback-endâ: File contains a Jet table with 100,000 records. The front-end .mdb queries the shared-file, requesting only the first record in the table. One lousy record. Because the back-end file isnât a true client/server backend (isnât a database server that can handle the query processing workload and return that one lousy record to the front-end) all 100,000 records are sent over the wire to the front-end .mdb file for processing. All the query processing is handled by the Jet engine on the front-end.
Database Server back-end: Database contains a SQL Server table with 100,000 records. The front-end .mdb queries and off-loads the query processing workload to the database-server, requesting only the first record in the database table. Because the database server is a true client/server backend, the query is processed on the server, and 1 record is sent over the wire to the front-end .mdb.
The forgoing obviously has huge ramifications for multi-user application development, network traffic considerations, performance, scalability, etc.
Anyway, there isnât anything wrong with calling the two .mdb files created by the Database Splitter a front-end and a back-end. The important thing is to understand how your queries are processed in a shared-file vs. a client/server architecture. The rest is merely semantics.
HTH,
Bob
|
