關於資料規範與資料介面,個人建議

2021-04-13 10:01:20 字數 1018 閱讀 9225

大大小小作了不少的專案了,其中有幾個專案是我所困惑的!當然針對的是同乙個問題「資料介面」

最初的公司是做工商行業的,為了系統的正常執行,需要把總局與地方局的資料差異遮蔽掉,這就需要寫乙個介面來轉換,可是工作量大的驚人,各個地方的不一樣,導致總局的資料維護相當繁雜,河北省一套,河南又另外一套,……這樣各個省市下來,介面的實現是多麼的令人恐怖

現在的公司是做金融的,各個銀行的介面與銀聯又存在著大的差別,資料介面又來了,整日做著那些枯燥無味的工作。雖然不是我做的,但我以前的經歷讓我知道,這樣的工作實在是令人作嘔的

所以我提一些建議

資料的規範主要有以下幾種情況:

1、資料的格式(欄位的大小、型別)不一致

2、資料量(尤其是資料庫字段)不一致

3、資料的要求不一致(可否為空等)

4、資料儲存方式不一致(資料表,例如乙個欄位在這個系統是存在基本表,另外乙個系統卻存在不相干的表裡)

5、採用的儲存結構不一致(oracle,db2,sqlserver……)

各個行業間會有差異,這點是正常的,然而同乙個行業卻有如此大的差異,勢必會帶來維護的困難與成本的提高,更加不適合統一管理

往往資料介面的開發是做了乙個資料轉換的功能,將a系統的資料以b系統的規範進行轉換,並存到b系統裡,而當b系統轉到a系統的時候,再進行一次逆轉換,這樣一來,大家可以看到問題的複雜度了,只要有乙個地方要改,另外至少兩個地方甚至更多地方需要維護。所以我認為:

1、同乙個行業,最好同一一下資料格式,資料量,資料要求,以及儲存方式,結構

2、不同行業的資料傳遞也要規範化,比如,工商行業需要得到公安行業某個人的資料(姓名,**……)

3、系統要求最好一致,都使用相同的儲存介質,儲存結構(可以有行業老大統一發放格式規範)

所以這樣一來,就會減少工作量,加大維護質量。雖然會由於各方面的原因實施起來比較麻煩,但還是可以去做的,僅僅是我的建議  呵呵,希望大家不要拍磚

因為我原來的500w的專案,資料轉換用了將近一半的成本(各地蒐集資料,進行對比,進行轉換),而其他所有模組的開發就……大家可見一斑

好了,希望大家討論

資料庫相關規範建議

核心 1 不在資料庫做運算cpu計算務必移至業務層 2 控制單錶資料量 單錶記錄控制在1000w 3 控制列數量 字段數控制在20以內 4 平衡正規化與冗餘 為提高效率犧牲正規化設計,冗餘資料 5 拒絕3b 拒絕大sql,大事物,大批量 欄位類 1 用好數值型別 tinyint 1byte smal...

資料庫設計,建議規範

1 資料庫和表取名要有意義,最好不要超過32字元,命名都使用小寫字母或單詞並用下劃線隔開,字段最好不要有關鍵字等 2 臨時資料建議以tmp 為字首並以日期為字尾,備份資料建議以bak 為字首並以日期為字尾 3 資料庫和表的字符集統一使用utf8 表情用utfmb4 4 表和字段都要新增注釋 5 儲存...

關於資料庫命名規範

a z a z 0 9 和 共 63個 如 useriduser id 資料庫物件 規則 物件名字由字首和實際名字組成,他們之間加下劃線,不要在物件名的字元之間留空格,長度不超過30字元。物件名字 字首 實際名字 字首 使用小寫字母 表 tb 檢視 vi 索引 idx 關聯 rl 儲存過程 sp函式...