The advent of comparatively inexpensive PC networks throughout the 1980s and ’90s provoked an increased demand for scalable information systems with user-friendly human interfaces. Spreadsheet and desktop database software and graphical interfaces gave non-technical users a taste for the power of desktop computing. Once the sharing of files across networks and among different types of software became standard practice in large enterprises, the customers demanded more. Desktop and LAN-based data management also came within reach of the smallest businesses. Today, it is almost unthinkable to design an enterprise information system under the monolithic model of the mainframe and the text terminal.
Scalability is judged in two dimensions: horizontal and vertical. Horizontal scalability is the capacity of the system to accommodate additional users without impact on the capability of the software or resources. Vertical scalability corresponds with what it takes to reproduce the system on simpler or more complex platforms and hardware configurations in response to variations in load and access requirements. It ranges from the low end—making the system available to users of mobile devices, for example—to a high end that has no conceptual limit.
Client/server architecture for database systems evolved as a response to the fragility, low load capacity, and speed limitations of the file-sharing database model in PC networks as multi-user demand increased. Its emergence coincided with the parallel development of the SQL language. Both were, in part, strategies to neutralize the dependency on mainframe hardware and software that prevailed in the 1980s. True client/server architecture for databases is heterogeneous and interoperable —it is not restricted to a single hardware platform or a single operating system. This model allows clients and servers to be placed independently on nodes in a network, on hardware and operating systems appropriate to their function. Client applications can communicate simultaneously with multiple servers running on disparate operating systems.
The great flaw with file-served database systems is the vulnerability of data to error, damage, and corruption when it is physically accessible to file-sharing clients and placed under the direct control of humans. In the client/server database model, client applications never touch the physical data. When clients request changes to data state, the server subjects the requests to rigorous validation. It rejects requests that fail to comply with internal rules or metadata rules. When a write request is successful, the actual change of database state is executed entirely by code resident in the server module and within disk structures that are under the server’s control.
Distribution of Function
The client/server model allows the areas of work in the system to be distributed appropriately and effectively among hardware and software components. The database server takes care of storing, managing, and retrieving data and, through stored procedures, triggers, or other callable processes, it provides the bulk of data processing capacity for the system. The client process manages the “sharp end” for applications by translating their requests into the communication structures that form the protocols for database and data access.
Applications are the dynamic layer in the model. They provide a potentially infinite variety of interfaces through which humans, machines, and external software processes interact with the client process. For its part, the client module exposes itself to applications via a comprehensive, preferably standardized, language-neutral application programming interface (API).
In some systems, it is possible for applications to act almost entirely as deliverers of information and receptors of input, delegating virtually all data manipulation to the server’s processing engine. This is an ideal for client/server systems because it locates CPU-intensive tasks in which processing power is concentrated and leaves applications to utilize the capacity of the workstation to deliver the best-performing user interfaces.
At the other end of the scale are systems in which, through poor design or an impractical concern for interoperability, virtually all data processing is performed on client workstations. Such systems are often characterized by poorly performing user interfaces, delays in synchronizing database state, and unresponsive networks.
Between heaven and hell are well-performing client/ server database systems that make good use of processing capacity on servers while retaining some data processing functions on workstations where it is justified to reduce network traffic or improve the flexibility of task implementations.
The Two-Tier Model
Figure illustrates the classic two-tier client/server model. The middleware layer, which may or may not be present, represents a driver, such as ODBC, JDBC, or PHP, or a data access component layer that is integrated with the application program code. Other layerings at the client side are possible. Applications may also be written to access the API directly, with no middleware.
The two-tier client/server model
The N-Tier Model
Upscaling and requirements for greater interoperability give rise to a model with more layers, as shown in Figure. The client interface moves to the center of the model and is joined by one or more application server layers. In this central complex will be located middleware and network modules. The application layer becomes a kind of database superclient —being served by multiple database servers sometimes—and itself becomes a proxy server for database requests from applications. It may be located on the same hardware as the database server, but it could just as well be running on its own hardware.
The n-tier client/server model
Acknowledged standards for hardware and software interoperability and, especially, for metadata and query language are characteristic of client/server database systems. The rise of the relational database systems and the consolidation of SQL standards over two decades have been and remain inseparable. The abstract nature of well-designed relational database systems, along with their relative neutrality with respect to choice of application language for “front-ends,” ensure that the RDBMS continues to hold its place as the preferred database architecture for client/server back-ends.
That is not to dismiss other architectures, however. Although, for the time being, object database systems continue to be closely bound to application languages, object- relational (OR) architectures are making significant inroads into the relational tradition. The most recent SQL standards make several provisions for standardizing OR methods and syntaxes. When people start demanding standards for technologies, it is generally a good indication that the technology is expected to be around for a while.
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.