A client is a program submitting SQL requests to a database server via a network connection.
A client receives the results of a SQL query over the same network connection.
The client program often runs on a personal desktop computer, but can run anywhere.
Client programs often use Graphical User Interfaces (GUI's) to interact with the user.
A database server is a program accepting SQL requests from clients over multiple network connections.
One server can handle multiple clients. This implies that the server is multithreaded. Each client has a corresponding process inside the database server.
SQL processing and physical data file access occurs in the database server. The server performs data access coordination (locking), memory caching, and security processing.
In addition to data access, a Sybase server can also execute miscellaneous transaction processing logic. Data consistency and integrity checks don't have to be coded into each different client application. Instead they can be enforced centrally in the Sybase server.
You cannot do a SQL join across multiple database servers (at least for now).
One client can connect to multiple servers.
A client needs a username and password to open a connection to a database server.
Sybase does not sell computers, they sell software. In order to sell software, Sybase makes sure it runs on a wide range of computer architectures.
A Sybase server runs on:
The Sybase server can talk to a wide variety of clients through a set of networking protocols. These networking protocols include:
Sybase clients can be programs supplied by Sybase, programs supplied by independent software vendors, or user written programs.
Other Sybase produces called gateways to give clients and servers on line access to non-Sybase data.
Click here for a more detailed description of Transact-SQL.
Transact-SQL is Sybase's extension to SQL. Transact-SQL permits procedural processing with control statements like if..then, while, raiserror, and return.
The extensions to SQL are necessary so that the Sybase server can perform transaction processing as well as data access processing.
Transact-SQL includes the following types of statements:
Click here for more detailed descriptions.
Click here for a more detailed description of stored procedures.
Stored procedures are collections of Transact-SQL statements that are stored in the Sybase server.
Stored procedures include the following features:
Sybase stored procedures can be used to dramatically improve performance. Additionally, they can be used to place transaction related logic in a central location.
There are performance and resource usage benefits that come from using stored procedures. These benefits come from the fact that SQL in the stored procedure is compiled only once, not each time it is invoked. This especially becomes significant in a transaction processing type of environment.
Sybase stored procedures provide a means for Transact-SQL to be shared at run-time in the Sybase server. In this respect stored procedures are similar to Unix shared runtime libraries (.so) and Windows dynamic link libraries (.dll).
Stored procedures can contain application and transaction processing logic. This logic can be enforced across multiple applications. This is especially useful in an open client/server environment where there could be several different types of clients accessing the same data.
Triggers are a special case of stored procedures that can be invoked automatically and transparently.
Triggers are used to enforce referential integrity as well as higher level business rules. Triggers provide a guaranteed way to enforce rules without having to code the rules into each different application accessing the database.
Triggers are normally transparent to the client.
In the Object Oriented Design (OOD) methodology there are two main subjects:
A basic goal of OOD is to put functions close to the data they are associated with. As part of this design partition, it naturally follows that if the data is shared so are the functions that are associated with it.
Stored procedures can sort of be used in a OOD like manner. Business rules and application logic which is closely tied to a database table can be implemented in a stored procedure in that database.
In this way, centralized stored procedures can be used to prevent the need for each different application to code in the same set of business rules.
As with any software sharing, there are pro's and con's. It's difficult to properly share software. It's much faster to "write your own" than to find and figure out someone elses code. Additionally, once code is shared, changes to that code affect multiple projects. In the short run, it's usually easier to just make another copy and modify it. Eventually, this approach collapses.
Click here for a more detailed description of RPC's.
Sybase servers also include the ability to communicate directly between each other without going through a client.
The inter-server communication is implemented as an easy to write procedure call.
RPC's can be called in stored procedure or triggers so that the client program doesn't have to know or care about other sources of data.
Click here for a more detailed description of openservers.
The Sybase architecture includes a type of server which is not an SQL dataserver, but can still execute what appear to be stored procedure calls. This new type of server can perform user coded 3GL system programs. For example, an openserver can be developed to access flat files or send mail messages.
Openservers permit the Sybase architecture to extend into non- Sybase and non-relational environments. For example, an openserver can be used in an engineering organization to accept live data feeds from monitoring equipment.
A Net-Gateway is a Sybase supplied openserver which accesses CICS transactions and DB2.
These products represent the next generation of the Sybase architecture.
The Omni server looks like a single server to the client, but can actually talk to multiple physical servers using SQL. These physical servers can be Sybase, Oracle, or DB2 servers, or operating system level indexed files. A single SQL query to the Omni server is broken up into the appropriate subqueries to be sent to the physical servers or filesystems.
The Omni server will transparently join results data coming back from the physical servers and send it back to the client.
In an Omni server a table can actually be a local file. For example, DEC servers can use local RMS files as tables, Unix and NT can use ISAM files, and Netware can use Btrieve. Users can setup local files to hold table definitions and data. Users can perform regular SQL operations against these files as if they were tables. For example, a user could join a flat file to a real Sybase table.
Files can be treated as local data, which can placed, as needed, "locally" into the Omni files. The purpose of this serves to offload some processing from the RDBMS Servers typically connected to through Omni.
The Replication server efficiently and reliably duplicates data between Sybase servers. If connectivity is temporarily lost, changes are stored until they can be forwarded to the duplication site.
The Replication server is a compromise between the high cost and low availability of two-phase commit verses the ease of implementation and network usage optimization of data duplication.
figure - omni server
Small cheap client machines are relatively common and already on users desktops for other reasons (wordprocessing and spreadsheets).
Large numbers of client machines permit commercial software developers to spend more money on software development.
Big high power server machines can be shared by multiple users. Specialized administrative tasks can be centralized.
Clients can share a single copy of consistent data in the database server.
Clients can also share the transaction processing logic Data and application consistency rules don't have to be coded into every client.
Client programs need high speed access to local graphics, but relatively low speed access to data.
SQL queries typically need high speed access to multiple database tables in order to perform joins, but return relatively little data.
Multi-vendor network connectivity has to be supported. Client/network/server problems can be difficult to localize. Vendors will almost always blame each other.
Sharing processing logic in stored procedures has the same problems as sharing code in conventional ways. Changes cause ripples of side effects. Changes must be approved by a committee. Multiple stored procedures can be redundant. Users may not know which stored procedures to use.
Sybase SQL queries can't access data on multiple servers. Either redundant data has to be kept in each server or the clients have to perform special processing. The Omni server works around this problem by making multiple servers appear as a single logical server.