OOP and RDBMS do not match, who compromises, or to find a wishy-washy?

OOP and RDBMS mismatch OOP's object-oriented theory and RDBMS based on the relational theory is not the same thing, the theory is different, mismatch is very normal things, mainly have the following performance:
Granularity for the concept of clarity and responsibility of the single, the object of the design granularity is relatively thin. For example, a user object contains an address object with country, city and Street properties. However, in order to consider the performance, the database table design granularity is relatively coarse, for example, there may be a only user table, address aspects of the country, city and street, etc. only as fields. Polymorphic polymorphism is an OO feature, and inheritance structures are common, but RDBMS are not polymorphic. In the case of Java, the object identity is reference, which generally determines whether the object is the same with the Equals () method, while the identity of one row in the database table is the primary key association with an object associated with other objects by holding the reference of the other object, and there is a direction, Can be one-way, can also be two-way, can be one-on-one, a pair of more, many to many.        The two-table association in an RDBMS is a foreign key, with only one direction, one-to-one or many-to-many, and a relational table if more than one is needed. OOP and RDBMS contradictions are inevitable, just like the two brothers quarrel, the day is still to be passed, our program is still to write. Solve the problem of mismatch, generally the following three strokes: to the RDBMS compromise this is the most common, since you are the "relationship" database, then I do not oo it? As the database table structure is built, I'm programming around these tables. Whether it's directly on SQL or with a large number of VO that contains only data, in short, process oriented. The advantage is, easy to understand, so that the programmer is best to find; the technical and business of repeated code are too many, difficult to maintain, no aesthetic, only fatigue. Compromise to OOP, with an object-oriented database, I've never seen a legendary object-oriented database and will continue to be invisible for the foreseeable future. Using a wishy-washy as an intermediary to appease the two sides of the ood/oop I also Oo, the use of relational databases we also use, find an ORM tool to make both sides. This may be the best solution, even if not solve all the problems, can solve 90% of the problem, will greatly save our time, and greatly improve the system's maintainability. Everyone knows that the standard for ORM in the Java World is hibernate.