Original: http://zwwwxy.blogchina.com/blog/Article_81038.1423950.html
Today's data processing mode presents a significant addition of an intermediate layer layer in the middle of the expression layer and the data layer, on the one hand, in or mapping, the structured data in the relational database is mapped in memory; on the other hand You can directly access the properties required for these object extraction. Object databases start from ten years ago, the purpose is to meet the needs of this access to the intermediate layer transition, even envisioning the object directly in deposit into the database, thus speeding up the efficiency of data processing (eg oracle). However, due to the weakening of the inter-object between the objects, the data redundancy beyond the scope of the actual tolerance, it is not widely recognized.
For subsidiary / department mechanism, since each subsidiary is required to be independent management, the group role assigns the user's unit container, the complex object involved, mainly the subtribracle collection, such as services, channels, columns, etc. Wait, it is also more ground. If you use a traditional relational database - "Object mapping mechanism, it is a considerable project. Implementing it using XML, is the ability to use the XML object-based organization and Digester automatically fill the object properties, thereby reducing the underlying development. However, as participated in the subsidiary / department has become more and more, the usage of memory has become more and more, which produces the demand for the transfer of more permanent relational databases. However, the non-objective characteristics of the relational database itself cause it that it must have an OR to implement the accessible objects in the database in the database, which makes the transfer generate a paradox: either XML object stored value concept, or no relational database. And the only way to avoid the arrament, it seems to organize a relationship object database.
(Relationship) Object Database As early as ten years ago, Oracle also provides an object table for unified OID indexing, and provides a SQLJ object conversion layer. However, the object database has not become the main solution for data flooring after ten years, which must have a reason. In my opinion, the biggest difference between the object database and the relational database is the management of foreign keys. Foreign key is a unique concept of relational database. It is the index of the external base table that does not exist as a sub-table (List) object, and the sub-type of a base table is to be traversed. The outer key of the table see if the ID is in line with the ID. The appearance of the object database is to use the reference collection as a foreign key attribute for this inefficient multi-traversal (a multi-table connection to the relational database). In other words, in the object database, the foreign key is meaningless, the object reserves the collection of base objects in its own namespace, directly positioning the position of the self-sub-object, rather than by traversing the external set. Obviously, this efficiency is much higher; however, how to deal with the collection of itself, it has been issued, although the various databases have developed their own collection types, but they have not become the standard specification of SQL, and they cannot provide consistent icons SQL. Such a simple and efficient query language. Probably, this is a reason why the object database is still universal.
XML as a container for automatic management objects, is possible to play a resolution of this "query and object automatic transformation" role. My idea is to provide a field in the table, store the collection of related subtribracles of the object in XML, and use this field as a byte flow to Digester but the automatic interpretation of the interpretation of its subgroup. The object implements a DAO interface so that the object properties are read from the database if needed. In this way, all contradictions above are solved; there is no extra special encoding amount. Of course, as a support for this mechanism, a basic extension and the management of Jakarta.Digester / DAO must be developed. This mechanism must provide a tool for editing attributes with a direct XML storage method. To cancel the defect of XML after departure into the database. After reaching this step, it should be more than the traditional relationship ER design to map the memory object. Whether it is using EJB, JDO, or Hibernate, Librante, Hanva's or mapping method, efficiency is high, save two steps Work, and you can directly use XML as the exchange layer of different platforms. At the same time, it also saves the most troublesome multi-table connection in the relationship map. Imagine that there is no obvious flaw, the difficulty of achieving is not high; complete this feature is approximately a few days, and you can make it.
