rmn190

JavaPersistenceWithHibernate读书笔记(2)

1.2 The paradigm mismatch

can be broken into several parts-->we will examine one at a time-->start with a example that is problem free --> mismatch appear.

User: represent information about a user of the system.
BillingDetails: represent information about the user's billing details.

    public class User {
        private String username;
        private String name;
        private String address;
        private Set billingDetails;
        // Accessor methods (getter/setter), business methods, etc.
        ...
    }
    public class BillingDetails {
        private String accountNumber;
        private String accountName;
        private String accountType;
        private User user;
        // Accessor methods (getter/setter), business methods, etc.
        ...
    }

with the following SQL schema:
    create table USERS (
        USERNAME varchar(15) not null primary key,
        NAME varchar(50) not null,
        ADDRESS varchar(100)
    )
    create table BILLING_DETAILS (
        ACCOUNT_NUMBER varchar(10) not null primary key,
        ACCOUNT_NAME varchar(50) not null,
        ACCOUNT_TYPE varchar(2) not null,
        USERNAME varchar(15) foreign key references user
    )

relationship between the two entities is represented as the foreign key, USERNAME,in BILLING_DETAILS.

now it's straightforward to write JDBC code to insert,update,and delete information about users billing details.

make paradigm mismatch visible --> since address as a simple String,other classes will also carry address info -->create a separate Address class.

Should we also add an ADDRESS table?Not necessarily.It's common to keep address info in the USERS table(基于什么考虑要把这个ADDRESS也放进Users表里?a table join isnt needed),in individual columns.

 Basically, we have the choice of adding either several columns or a single column (of a new SQL datatype). This is clearly a problem of granularity.

 1.2.1 The problem of granularity
    Granularity refers to the relative size of the types you’re working with.

    For these and whatever other reasons, use of UDTs or Java types inside an SQL database isn’t common practice in the industry at this time.

    Our pragmatic solution for this problem has several columns of built-in vendor-defined  SQL types (such as boolean, numeric, and string datatypes). TheUSERS table is usually defined as follows:

    create table USERS (
        USERNAME varchar(15) not null primary key,
        NAME varchar(50) not null,
        ADDRESS_STREET varchar(50),
        ADDRESS_CITY varchar(15),
        ADDRESS_STATE varchar(15),
        ADDRESS_ZIPCODE varchar(5),
        ADDRESS_COUNTRY varchar(15)
    )

Classes in our domain model come in a range of different levels of granularity-- from coarse-grained entity classes like User, to finer-grained classes like Address, down to simple String-valued properties such as zipcode. In contrast, just two levels of granularity are visible at the level of the  SQL database: tables such as USERS, and columns such as ADDRESS_ZIPCODE.

1.2.2 The problem of subtypes