主键生成器总结：
1。assigned
主要有外部程序负责，hibernate无需参与。
2。hilo
通过hi/lo算法实现的主键生成机制，需要额外的数据库表保存主键生成历史状态。
3。seqhilo
与hilo算法相似，通过hi/lo算法实现主键生成机制，只是主键历史状态保存sequence中，适用用支持sequence的数据库如oracle。
4。increment
主键按数值顺序递增，此方式的实现机制为在当前实例中维持一个变量，保存着一个最大值，之后每次生成主键的时候把此值增加1.
这种方法可能产生的问题是：当多个实例一同访问同一数据库时，由于各个实例各自维护主键状态，不同实例可能产生同一主键，造成主键重复异常，所以如果一个数据库有多个实例访问，此方法必须避免使用。
5。identity
采用数据库自己提供的主键生成机制，如db2、sql server、mysql的主键生成机制。
6。sequence
采用数据库中提供的sequence机制生成主键，如oralce提供的sequence机制。
7。native
由hibernate根据底层数据库自行判断用hilo，identity，sequence中的一中主键生成方式。
8。uuid.hex
由hibernate 128位唯一值产生算法生成16进制数值（编码后以长度32的字符串表示）作为主键。
9。uuid.string
与uuid.hex相似，只是生成的主键未进行编码（长度16），在某些数据库中可能出现问题（Postgresql）。
10。foreign
适用外部表的字段作为主键。
如果主键字段为自增类型，
那么对应的.hbm.xml文件中的id字段的xml声明，
应该这么写：
例如：
name=”Id”
type=”integer”
>
其实这个native并非实际的类型，而是hiberante根据
当前使用的数据库，自动使用对应的类型。
例如：如果sqlserver，native就对应identity
native（本地）
根据底层数据库的能力选择identity, sequence 或者hilo中的一个。
如果主键字段不设置为自增，但是是int型的，
可以使用increment，由hibernate产生主键。
不过这种方法，对于并发量大的应用，似乎最好不要采用。
见hiberante参考：
increment（递增）
用于为long, short或者int类型生成唯一标识。只有在没有其他进程往同一张表中插入数据时才能使用。
在集群下不要使用。
如果使用uuid.hex产生的随机32位数最为主键，
那么数据库的id字段类型为char，长度为32
hbm.xml中写为：
另外，uuid.string也是功能类似。
uuid.hex产生的是32位的16进制数字的字符串。
而uuid.string产生的是16个字符长的任意ASCII字符组成的字符串
uuid.hex
用一个128-bit的UUID算法生成字符串类型的标识符。在一个网络中唯一（使用了IP地址）。UUID被编
码为一个32位16进制数字的字符串。
uuid.string
使用同样的UUID算法。UUID被编码为一个16个字符长的任意ASCII字符组成的字符串。不能使用
在PostgreSQL数据库中