JavaPersistenceWithHibernate读书笔记(5)

1.2.5 The problem of data navigation(数据navigation问题)
    在Java里与relational database里数据navigation有很根本的不同.在Java世界里,当我们要想访问一个User里的billing information时,我们可以通过下面的方式就可以了:
        aUser.getBillingDetails().getAccountNumber();
    不过,很不幸的是,这并不是从SQL里取数据的efficient方式.
    
    为了提高数据库的访问性能,一个很重要的原则就是尽量地减少对数据库的访问次数,而这里最为明显的措施就是减少SQL的查询语句.(Of course, there are
other more sophisticated ways that follow as a second step.这个other more sophisticated ways又在哪呢?)
    
    于是,用SQL访问数据库的高效方式就是用joins来连接所涉及的表.表的数量多少也就决定了the depth of the object network you can navigate in memory.     
    For example, if you need to retrieve a User and aren’t interested in the user’s billing information, you can write this simple query:
        select * from USERS u where u.USER_ID = 123
    On the other hand, if you need to retrieve a User and then subsequently visit each of the associated BillingDetails instances (let’s say, to list all the user’s credit cards), you write a different query:
        select *
            from USERS u
            left outer join BILLING_DETAILS bd on bd.USER_ID = u.USER_ID
            where u.USER_ID = 123
    
    正如上面我们看到的那样,为了高效地应用joins这个特性,我们事先得得知想访问的object network中的别的部分(如上面提到的BILLING_DETAILS).
As you can see, to efficiently use joins you need to know what portion of the object network you plan to access when you retrieve the initial User—this is  before you start navigating the object network!

    然而,当一个对象首次accessed时,any object persistence solution提供了功能以获得与之关联对象的数据.不过,这个piecemeal style of data access is fundamentally inefficient in the context of a relational database,because it requires executing one statement for each node or collection of the object network that is accessed(这句话说的什么呢?each node怎样?collecton of the object network又怎样?这个与executing one statement又怎样呢?). This is the dreaded n+1 selects problem.(这里的n+1是什么意思?n+1是指n+1次访问BD,还是这个n指User下的n个BILLING_DETAILS?这样就很是浪费:一是数据库端多表join的浪费,二是那么多个BILLING_DETAILS信息传送时浪费,三是传来放到内存中的浪费.)
    在Java世界里与Relational database世界里访问数据方式的不同或许是Java应用中性能问题的一个根本原因.There is a natural tension between too many selects and too big selects, which retrieve unnecessary information into memory. Yet, although we’ve been blessed with innumerable books and magazine articles advising us to use StringBuffer for string concatenation, it seems impossible to find any advice about strategies for avoiding the n+1 selects problem. Fortunately, Hibernate provides sophisticated features for efficiently and transparently fetching networks of objects from the database to the application accessing them. We discuss these features in chapters 13, 14, and 15.

1.2.6 The cost of the mismatch
We now have quite a list of object/relational mismatch problems, and it will be costly (in time and effort) to find solutions, as you may know from experience. This cost is often underestimated, and we think this is a major reason for many failed software projects. In our experience (regularly confirmed by developers we talk to), the main purpose of up to 30 percent of the Java application code written is to handle the tedious SQL/JDBC and manual bridging of the object/relational paradigm mismatch. Despite all this effort, the end result still doesn’t feel quite right. We’ve seen projects nearly sink due to the complexity and inflexibility of their database abstraction layers. We also see Java developers (and DBAs) quickly lose their confidence when design decisions about the persistence strategy for a project have to be made.

 One of the major costs is in the area of modeling. The relational and domain models must both encompass the same business entities, but an object-oriented purist will model these entities in a different way than an experienced relational data modeler would. The usual solution to this problem is to bend and twist the domain model and the implemented classes(是要把这个domain model及其实现类"打磨"至这些实现类与SQL的schema相符为止?那也就是说要把domain model往BD端靠了,这个靠也就意味着Hibernate里的自动生成BD schema没什么用了?那这个与前面的legacy问题时一段话岂不冲突?因为前面说的是可能会遇到一些legacy DB schema,这个意思说Hibernate会自动生成DB schema吗?有些乱了....) until they match the SQL database schema. (Which, following the principle of data independence, is certainly a safe long-term choice.)
 
 This can be done successfully, but only at the cost of losing some of the advandages of object orientation(这名话的意思并不会最终bend and twist to SQL DB schema了?). Keep in mind that relational modeling is underpinned by relational theory. Object orientation has no such rigorous mathematical definition or body of theoretical work, SO WE CAN’T LOOK TO MATHEMATICS TO EXPLAIN HOW WE SHOULD BRIDGE THE GAP BETWEEN THE TWO PARADIGMS—THERE IS NO ELEGANT TRANSFORMATION WAITING TO BE DISCOVERED. (Doing away with Java and SQL, and starting from scratch isn’t considered elegant.)
 
 The domain modeling mismatch isn’t the only source of the inflexibility and the lost productivity that lead to higher costs. A FURTHER CAUSE IS THE  JDBC API ITSELF.  JDBC and  SQL provide a  statement-oriented (that is, command-oriented) approach to moving data to and from an SQL database. If you want to query or manipulate data, the tables and columns involved must be specified at least three times(怎么说至少要三次呢?) (insert,  update,  select), adding to the time required for design and implementation. The distinct dialects for every SQL database management system don’t improve the situation.
 
    To round out your understanding of object persistence, and before we approach possible solutions, we need to discuss application architecture and the role of a persistence layer in typical application design.