DB_ID_UUID_开题（一）
数据库的主键，按照道理来讲，应该是逻辑独立的，即其唯一作用是标识一行的唯一性。不过有人偏偏要加入逻辑意义，那就看实际需求了。
这个ID是很重要的，设计不好，会出现update的很多异常。所以纵观很多数据库厂商，都有自己的ID生成方式和管理。
MySQL：auto increment
Oracle：sequence
Informix：serial
（本人仅仅熟悉这3个数据库）
这已经很好使用了，本来想着够用了吧，应该不会有问题了吧。但问题还是存在。
1. 如果是多个数据库服务器集群呢，如何让ID保持统一
2. 安全问题，完全暴露了系统的工作方式。
比如公司的订单，或者costomerID，如果让别人窥探并利用，恐怕要有损失。这也是本人最近刚碰到问题。
3. 夸数据库问题
虽然说夸数据库或者更换数据库并不频繁，但总会有需求。比如本人曾经碰到的例子，电信公司不同省市所用的数据库不一样，如果用数据库内嵌的ID工作方式，更换数据库的时候就会碰到问题了。
虽说有Spring、Hibernate等工具，但使用不当，切换数据库也是个不小的工作。
针对上面的问题，解决方法有几个。
1. 自己模仿ID序列的生成方式，自己管理ID
好处是：随便夸数据库，反正是自己的。
坏处是：管理成本（深有体会啊~）；数据库集群问题；
2. 加密的ID
这样可以解决重要ID暴露的问题。
但也会带来加密解密的问题，比如加密解密本身的问题，加密解密的成本开销等。
3. UUID也许不错==>>
待研究~~
页:
[1]