在不一樣的公司的不一樣項目場景下,絕大多數狀況下都須要維護一些基本的維度信息(也稱爲字典信息,下面所有使用維度信息代替描述),好比旅遊相關的網站,可能會維護:網站
諸如此類的維度信息。並且每每這些維度信息可能不一樣的業務部門都須要使用所有或者其中的某些的某些。所以隨着時間的推移,這些維度類型可能會新增,修改,刪除某些項。致使不一樣部門維護的維度信息不一樣,可是每每公司中的部門不是獨立存在的,每每都須要互相交互。所以會涉及到維度信息的轉換。設計
咱們都知道統一維度的重要性,這一點怎麼強調都不爲過。可是每每現實是存在太多的維度不統一的場景了,在維度已經不統一的狀況下,咱們應該如何去逐步改善這些場景。code
所以本文主要着眼於我在實際工做中遇到過的問題,作一個總結,但願對你們有幫助。索引
通常咱們是如何使用維度信息的呢?比較通用的解決辦法每每是:接口
我想絕大多數項目應該都是這樣來解決維度信息的存儲和使用問題的。可是有如下的一些注意點:開發
這種使用方式每每會存在什麼問題呢?假設有3中類型的維度信息:A、B、C:rem
第一個問題:系統1僅僅使用了維度A,而系統2使用了維度A和維度B,系統3使用了維度B和維度C。
而系統一、系統二、系統3都有本身的數據庫。請問這個使用,這些維度信息的字典表創建在哪一個系統的數據庫中?仍是說每一個系統都創建一份字典表?同步
第二個問題:結合第一個問題,一樣,每每每一個系統都會有對應一個或者若干個工程項目,這些維度信息是哪些系統用到了就建立對應的枚舉,仍是統一維護一個工程,把全部的維度枚舉都寫在裏面,統一維護?產品
上面的2個問題,實際上是同一個問題,就是數據的一致性問題。當同一類信息存在的地方越多,一致性的問題越顯著。也越須要迫切的解決。由於若是不及時有效的解決的話,系統中會存在各類各樣的Adapter來進行維度信息的轉換工做。
這樣當新增,或者修改維度信息的時候,咱們會在「維度維護系統」的界面上進行維度信息的新增、修改操做。而後根據上面第四條描述的,根據維度系統的數據庫中記錄的「哪些繫有哪些維度表」的對應關係,而後程序自動新增、修改這些周邊系統的維度字典表數據。
固然當新增一種以前不存在的維度信息的時候,一開始只會在「維度維護系統」的數據庫中建立,而後哪些系統須要使用,就同步哪些系統。
數據庫維護之後,而後更新升級咱們的jar包就能夠了。
經過這種方式咱們在很大的程度上解決了維度信息的不一致問題。
爲了方便開發人員統計每一個系統有哪些字典表,咱們在設計字典表的表名稱的時候,統一採用了:_dict
結尾。好比產品線字典表的表名爲:product_line_dict
爲了方便程序處理,咱們也統一了表的格式:
use test; set names utf8mb4; create table product_line_dict( id int(10) unsigned not null auto_increment comment '維度序號', code varchar(32) not null comment '維度編號', name varchar(32) not null comment '維度名稱', primary key(id), unique key uniq_idx_code(code) )engine=innodb default charset=utf8mb4 comment '產品線維度表';
好比對於上面提到的product_line_dict表:
id code name 1 flight 機票
其中id爲表的主鍵,code列加惟一索引。另外系統說明的是表級別的comment註釋都是必需要寫清楚的。這樣方便新人閱讀數據庫表。
比起字典表只有:id、name這兩列來講,這樣的好處是: