DB2里头新加了Schema，感觉数据管理好像能更顺手点儿了

（一）

前几天在搞DB2,顺手给它加了个Schema，这事儿挺小的，但用了一会儿，感觉像给乱七八糟的抽屉装上了几个隔板，东西一下子就好找了，以前所有表啊、视图啊，都堆在一块儿，名字还得绞尽脑汁地想，生怕重复，现在好了，能按不同的“项目”或者“功能模块”给它们分个类，扔到不同的Schema里头去，我把所有跟用户相关的表都放在一个叫USER_AREA的Schema里，把订单相关的放在ORDER_AREA里，这么一来，数据库里头清清爽爽，心里也跟着透亮了。

（二）

最直接的感受就是,权限管起来特别省心，以前要是想给开发团队开一部分表的权限，得一张表一张表地授权，麻烦得很，现在不用了，我直接操作Schema这个层面就行，我把USER_AREA这个Schema的使用权限给小王，那他就能管里头所有的东西，我不用再惦记着里面是不是又新加了哪张表忘了给他权，反过来，有些特别敏感的数据，比如放财务数据的FINANCE_SCHEMA，我直接把这个Schema的权限收紧，只给一两个人，那就等于给这批数据上了把大锁，安全多了，这就好比是，我把一个房间的钥匙给了你，房间里所有抽屉你都能打开，而另一个房间我锁死了，谁都进不去，这种控制力，让管理变得特别清晰。

（三）

还有个好處是, naming conflict（命名冲突）这事儿基本就告别了，我们有时候会有些公共的表，比如每个项目可能都想有个自己的config配置表，要是没Schema，那就得起名叫project_a_config，project_b_config，名字又长又啰嗦，现在呢，直接在PROJECT_A的Schema里建个config表，在PROJECT_B的Schema里也建个同名的config表，它们俩井水不犯河水，一点事儿都没有，这给写SQL也带来了方便，特别是当你要跨不同业务模块查数据的时候，一看Schema名，就知道这表是干啥的，不容易搞混。

（四）

感觉Schema这东西,有点像给数据库里的对象弄了个“姓氏”，光有名字（比如orders）可能重名，但带上姓氏（比如ORDER_AREA.orders），一下就唯一了，这种逻辑上的隔离，让数据库的结构更能反映出现实业务的组织方式，业务上有几个相对独立的单元，我就在数据库里建几个Schema把它们装起来，以后不管是新来的同事看数据库结构，还是我们自己隔了半年回头维护，都能根据Schema的名字快速定位到相关的数据资产，不至于像以前一样在表海里捞针。

（五）

当然啦,一开始可能会觉得多了一层，有点麻烦，但用顺手之后，就发现这点前期的麻烦，换来的是后期管理和维护上巨大的轻松，它没有改变DB2底层任何核心的东西，只是在上层做了一个非常巧妙的逻辑分组，就像整理房间，你花半天时间买了几个收纳盒，把东西分门别类放好，以后找什么都快，看着也舒服，Schema起的就是这个“收纳盒”的作用，现在我觉得，要是数据库稍微复杂点，表超过二三十张，不用Schema来管理一下，简直有点对不起自己，这确实是个能让数据管理变得更顺手的好东西。