rapidfx: переводы

→This combination should be sufficient to allow a developer to write trial applications. Future releases of Inferno may include new versions of the DB module and additional database server programs (to improve efficiency and security, for instance), but applications written to the current API should not need to be changed.

→The "standard" database application included in Inferno Release 1.0 is an ODBC application that runs on Windows 95 and Windows NT and talks to the DB module (no intermediate hosted Inferno is needed). This program, called infdb, will support simultaneous connections from multiple Inferno processes to the same, or different, databases.

→Release 1.0 of Inferno includes a DB module with the complete API described above, except that it doesn't have the ability to update binary data fields.

→This standard method for accessing database from Inferno involves several different software processes and interprocess communications methods. There are ways to improve the efficiency of database access where large amounts of data are transferred for each transaction, and the Inferno team is actively pursuing this. But, since all the changes will be to the remote access piece and will not affect the APIs, applications written today against the DB API will not even need to be recompiled to run when these improvements are put in place. Inferno 1.0

→There is a hosted Inferno on the database platform to serve the special files representing the database to the DB module. There are quotes around "standard" in the Database App. box because even though this application is the same for all databases under this DBMS on this platform, it must be different for different DBMSs, and must be ported to each platform where support for a particular DBMS/database is needed. (The DBMS/database could actually be on some other platform the details of the connection from the database application to it are hidden by vendor code bound into the application.)

→For Inferno support of a database, the generic architecture is:

→The net result of all this is that database applications are connected to the database via some opaque glue which is supplied by the DBMS vendor, and are typically written in C language, perhaps requiring a preprocessing step before compilation.

→Vendors have also lately begun to supply servers to allow databases supported by their DBMS to be accessed by client applications over a network. Again unfortunately, the protocols used by these servers are proprietary.

→A common instance of a CLI is the Open Database Connectivity (ODBC) interface, running on various Microsoft Windows platforms. ODBC is not tied to any particular DBMS, but depends on DBMS vendors to provide a driver, in the form of a dynamically loadable library that supports a prescribed set of APIs. Since there are now such drivers for most major DBMSs, ODBC provides an "almost universal" database access, as long as one sticks to the lowest conformance levels for both ODBC and SQL.

→Finally, vendors have not hesitated to provide proprietary extensions to SQL and to their CLIs.

→In addition, there are several programmatic interfaces to SQL, including static and dynamic embedded SQL and call level interface (CLI). The former are techniques for embedding SQL statements within other languages, calling for the use of a preprocessor. The difference between the static and dynamic versions is that in the former, the SQL statements are fixed at compile time, while in the latter they can be constructed at run time. A CLI is a set of APIs supported by a function library.

→Unfortunately, SQL is an evolving standard. The original standard was adopted in 1986, there is an SQL 89, the current SQL 92, and another in the works. While the changes are upward-compatible, different releases of the various vendor's DBMSs support different standards.

→The second bullet arises from the historic interplay between the desire of vendors for product differentiation and the desire of users for standardization. Structured Query Language (SQL) is an early, and continuing, effort to standardize the syntax and semantics of messages between database applications and DBMSs. The majority of commercial DBMSs now support SQL.

→the diversity of existing DBMS products makes it difficult to write generic database access programs.

→existing DBMSs run on platforms other than Inferno, and

→The second piece of software provided for Inferno support of databases is the server. The application programmer does not interface directly with the server, which hides the complexity of retrieving data from real databases. This complexity is because:

→The advantage of this implementation is that the data being sent back and forth from client to server is encapsulated in Styx packets, so the security features of the Styx protocol may be used. The Server Module

→Closely paralleling the API, the served files are: ctl, SQL, cols, row, entry, and title. The ctl file is used only to send the user name, password, and database name to the remote end. The SQL file is used to write SQL requests to the far side, and the remaining files are used to implement the remaining APIs. For instance, to implement the read function, the specified column number is written to the cols file, and then the entry file is read, up to an end-of-file, to get the value of the field in that column of the current row.

→The DB module makes direct use of Inferno's name space concepts to implement its simple design. In particular, the open function opens a network connection to the specified service at the specified network address. By mounting the connection on a directory in the local name space, the remote end is set to "serve" files in that directory. Following the open, the served files support the functions of the API, or if the programmer prefers, can be read from of written to directly via file descriptors in the DB_Handle adt.

→Database application developers can build more complex and specialized functions out of these generic and lower-level functions. Module details