【正文】 1 英文文獻 Object persistence and Java By Arsalan Saljoughy, , 05/01/97 Object durability, or persistence, is the term you often hear used in conjunction with the issue of storing objects in databases. Persistence is expected to operate with transactional integrity, and as such it is subject to strict conditions. (See the Resources section of this article for more information on transaction processing.) In contrast, language services offered through standard language libraries and packages are often free from transactional constraints. As we39。ll see in this article, evidence suggests that simple Java persistence will likely stem from the language itself, while sophisticated database functionality will be offered by database vendors. No object is an island In the real world, you rarely find an object that lacks relations to other objects. Objects are ponents of object models. The issue of object durability transcends the issue of object model durability and distribution once we make the observation that objects are interconnected by virtue of their relations to one another. The relational approach to data storage tends to aggregate data by type. Rows in a table represent the physical aggregate of objects of the same type on disk. The relationships among objects are then represented by keys that are shared across many tables. Although through database organization, relational databases sometimes allow tables that are likely to be used together to be colocated (or clustered) in the same logical partition, such as a database segment, they have no mechanism to store object relationships in the database. Hence, in order to construct an object model, these relationships are constructed from the existing keys at run time in a process referred to as table joins. This is the same wellknown property of the relational databases called data independence. Nearly all variants of object databases offer some mechanism to enhance the performance of a system that involves plex object relationships over traditional relational databases. To query or to navigate? In storing objects on disk, we are faced with the choice of colocating related objects to better acmodate navigational access, or to store objects in tablelike collections that aggregate objects by type to facilitate predicatebased access (queries), or both. The colocation of objects in persistent storage is an area where relational and objectoriented databases widely differ. The choice of the query language is another area of consideration. Structured Query Language (SQL) and extensions of it have provided relational systems with a predicatebased 2 access mechanism. Object Query Language (OQL) is an object variant of SQL, standardized by ODMG, but support for this language is currently scant. Polymorphic methods offer unprecedented elegance in constructing a semantic query for a collection of objects. For example, imagine a polymorphic behavior for acccount called isInGoodStanding. It may return the Boolean true for all accounts in good standing, and false otherwise. Now imagine the elegance of querying the collection of accounts, where inGoodStanding is implemented differently based on business rules, for all accounts in good standing. It may look something like: setOfGoodCustomers = (())。 While several of the existing object databases are capable of processing such a query style in C++ and Smalltalk, it is difficult for them to do so for larger (say, 500+ gigabytes) collections and more plex query expressions. Several of the relational database panies, such as Oracle and Informix, will soon offer other, SQLbased syntax to achieve the same result. Persistence and type An objectoriented language aficionado would say persistence and type are orthogonal properties of an object。 that is, persistent and transient objects of the same type can be identical because one property should not influence the other. The alternative view holds that persistence is a behavior supported only by persistable objects and certain behaviors may apply only to persistent objects. The latter approach calls for methods that instruct persistable objects to store and retrieve themselves from persistent storage, while the former affords the application a seamless view of the entire object model often by extending the virtual memory system. Canonicalization and language independence Objects of the same type in a language should be stored in persistent storage with the same layout, regard