1. 資料庫怎麼設置兼容級別！
查看或更改資料庫的兼容級別
連接到 SQL Server 資料庫引擎 的相應實例之後，在對象資源管理器中，單擊伺服器名稱。
展開「資料庫」，然後根據資料庫的不同，選擇用戶資料庫，或展開「系統資料庫」，再選擇系統資料庫。
右鍵單擊資料庫，再單擊「屬性」。
「資料庫屬性」對話框將打開。
在「選擇頁」窗格中，單擊「選項」。
當前兼容級別顯示在「兼容級別」列表框中。
若要更改兼容級別，請從列表中選擇其他選項。可用選項包括SQL Server 2005 (90)、SQL Server 2008 (100)或SQL Server 2012 (110)。
2. 如何實現Oracle，Mysql，SqlServer資料庫的兼容
沒個資料庫的語法總會有那麼點
或多或少的區別，你說的兼容
是指
做項目的時候，切換不同的資料庫，而只需寫一種語句么？如果是的話，那我推薦你使用
Hibernate
，給它配置
sessionFactory
，幾個資料庫，就寫幾個sessionFactory
，這樣就能只需寫個hql語句，就能實現我說的
切換資料庫了，不知道
是不是你需要的
3. 表格改變欄位時，該如何兼容歷史數據
業務是不斷變化發展的，產品也是會隨之不停迭代的，數據表格作為基本組件也常常需要變動，這在我們的日常工作中是非常常見的。
比如下面這個例子，一款分析淘寶商家移動端店鋪數據的產品，其中菜單「流量來源」是對店鋪流量的分析，在店鋪發展初期「淘內免費」、「付費流量」、「自主訪問」能夠支撐業務方對於店鋪數據的分析，但是隨著店鋪業務不斷發展做大做強，對於流量分析的顆粒度要求越來越細，只是對流量的簡單劃分已經無法滿足業務方的需求。希望能對於淘內流量能有更細的分類，幫助業務方對店鋪流量有更細致的了解，從而根據不同流量大小調整運營策略，促進店鋪銷售數據的發展。
現狀：淘內免費 付費流量 自主訪問
期望：手淘搜索 我的淘寶 淘內免費其他 手淘微淘 手淘掃一掃等
需求：改動「流量來源」數據表格中的欄位
當原有產品無法滿足當前的業務發展時，為了滿足業務的新需要，服務於新的場景。不得不要求我們去改變最初的產品設計，改動表格中的欄位設計。而改動「數據表格」的欄位很容易引發數據沖突的情況，包括數據類型沖突、數據格式沖突等。
如果在改動表格欄位時，不去考慮數據沖突的影響，不去考慮如何兼容歷史數據，會導致產品內的數據在完整性和一致性上出現問題，比如上文中案例如果不進行歷史數據兼容處理，選擇在3.19號上線新的統計功能，關於流量的劃分就會存在兩種不一樣的統計方式，19號前的流量數據劃分方式和19號之後不一致，按月維度下沒有辦法對3月的流量數據做一個統一劃分。
歷史數據一定意義上成為了「臟數據」，有句話說的好叫「垃圾數據進垃圾數據出」，數據質量對於分析結果的重要性甚至高於分析方式和模型。混入臟數據後產出的結果對業務造成嚴重的影響，甚至做出了錯誤的決策，帶來不可磨滅的損失
因此，我們有必要去解決「表格改變欄位」後產生的數據沖突，去兼容歷史數據，減少改動對數據產生的負面影響。那麼問題來了，我們該怎麼去兼容歷史數據呢？
01 歷史數據都是需要保留的嗎
表格改變欄位出現數據沖突的情況後，在我們去兼容歷史數據之前可以先思考一個問題：歷史數據都是需要保留的嗎？一起來看下下面的兩個場景。
場景1
某電商to b產品，在一次迭代中，對「店鋪銷售」菜單增加了「客單價」欄位，那麼歷史數據中的客單價對我們有意義嗎？
場景2
我們設計了一套問卷用於統計「國內大學生的不同專業的就業情況」，投放問卷一段時間後對問題就行了修改，那麼收集的歷史數據對我們還有意義嗎？
通過兩個具體的場景，我們可以發現「歷史數據」在不同的場景下的保留策略是不同的：
場景1中的「客單價」能幫助復盤店鋪歷史的客單價情況，和當前時間的「客單價」進行對比，對店鋪策略起到數據指導作用，在此場景下歷史數據具有重要意義，需要保留。
而場景2中收集的「你的國家是什麼」和場景題干「國內大學生」矛盾，問卷的修改也是為了解決這一矛盾才修改題目的，所以該題目收集來的歷史數據無效，不需要保留可以直接廢棄。
歷史數據是對過去業務情況的記錄和反饋，但並不是所有的歷史數據都是有意義的，也不是所有歷史數據都需要保留的。當需要考慮歷史數據兼容問題前，建議先從實際的場景出發去分析一下「歷史數據」對於業務的價值和意義，如果關聯不大或者本身就是錯誤的數據，直接廢棄歷史數據就OK了。對於要保留的歷史數據，才需要去考慮沖突在哪裡，以及怎麼去兼容
02 怎麼去兼容歷史數據
在我們思考了歷史數據的價值和意義之後，確定要保留歷史數據，那麼我們怎麼去兼容歷史數據呢？首先，我們需要區分不同的數據表格改變方式，會帶來怎麼樣的數據沖突，再根據不同的沖突情況去提出相對應的兼容方案
1. 增加欄位
我們經常會遇到在表格上「增加欄位」的情況，比如增加了新的業務欄位，增加了新的統計項。
如果不做兼容處理，就會出現增加的欄位有增加後的新數據，但是沒有歷史數據。這種情況下，需要我們判斷歷史數據能否被補全，若能，則補全歷史數據；若無法補全，新增的欄位歷史數據空白展示。
2. 減少欄位
當出現「減少欄位」的情況，如果不做處理，會出現減少的欄位沒有新數據，但是有歷史數據。這種情況下，我們的處理方式是保留歷史數據，減少統計後該欄位空白展示。
3. 原欄位統計邏輯或規則改變
統計邏輯或規則被改變時，不進行數據兼容的話，因為新數據和歷史數據的統計方式不一致，會導致數據結果出現差異。這個時候，需要我們去判斷歷史數據能否按新的統計邏輯換算，若能，則按新邏輯重新統計；若不能保留歷史數據，並記錄統計邏輯的改變記錄。
4. 原欄位下鑽或合並統計
這種改變會出現新欄位和歷史欄位是包含或者被包含的關系，需要我們去補全歷史數據，比如欄位A被下鑽成了新欄位B+新欄位C，根據下鑽規則補全新欄位B和C的歷史數據值。
而在實際的場景中，數據沖突會同時存在多種，所採用的方案也是多個解決手段組合的。
比如下面這個案例，我們對「客戶管理」模塊進行迭代，通過調研發現內部銷售團隊希望能在「客戶管理」菜單中增加「客戶微信」欄位，並提供根據客戶等級自動計算出「下次回訪時間」，為此我們對「客戶管理」的欄位進行了調整。
表格改動為：增加「客戶微信」、「下次回訪時間」欄位，減少「創建時間」欄位。這里就涉及到了「增加欄位」和「減少欄位」兩種情況，通過分析「客戶微信」和「下次回訪」欄位對存量客戶具有重要意義，收集到客戶的微信聯系方式和具體的回訪時間，方便業務員展開業務，兩個欄位的數據也有被補全的條件；而減少的「創建時間」欄位對於業務影響不大，可以廢棄。基於上面的考慮，我們對「客戶管理」菜單做了如圖處理。
迭代發布上線後，產品同學提出「下次回訪時間」直接展示時間，對銷售團隊來說不夠直觀，可以對「下次回訪時間」進一步處理，更加直接明了，因為「下次回訪時間」欄位中原有的時間格式是支持現在的規則換算的，就可以對時間進行了換算處理。
對「下次回訪時間」的展示進行處理，計算「下次回訪時間」和當前時間的差值：
原統計格式：yyyy-mm-dd
新統計格式：X天後回訪；已過期X天
隨著業務的發展又遇到了「欄位統計邏輯和規則無法轉化」的情況，「客戶管理」中「意向產品」的可選項從「商品1，商品2，商品3」變成了「商品5，商品6，商品7」，改動前後的數據沒有辦法去簡單的進行兼容，而前後數據對於業務來說都是具有意義的，那麼我們需要在保留兩者數據格式的前提下，做一些文案上的提示，例如在操作日誌記錄系統對於規則的更改。
從上面這個案例中我們發現，表格的變動不單單只有出現一種沖突，我們採取的解決方案也是多樣的。
03 兼容歷史數據的價值和場景
表格欄位的改動會導致歷史數據和改動後數據的沖突，而數據沖突會導致在產品層面的數據沒有連貫性，進一步導致了用戶無法理解前後數據，對產品產生了疑問，以至於產生了負面情緒。
簡單的對表格欄位進行增減，對於用戶的影響相對於較少，降低了用戶對數據的可讀性，比如上文案例中增加減少欄位，不做處理的話，用戶會對部分情況有數據部分情況無數據產生疑惑增加了理解成本。
但是對於更改統計邏輯的，就不只是簡單用戶體驗上的問題了，會給業務帶來實際的影響，比如上文中意向產品中可選擇的產品變更了，如果不及時對於歷史數據進行兼容，做相關的變動說明處理，很容易給業務員帶來之前的商品仍然可以進行銷售的誤判，最終導致下錯訂單甚至下單後無法發貨，給公司業務帶來實質的虧損
由此可見，兼容歷史數據的價值，在於解決這一系列的數據沖突，既保證了產品層面的數據連貫性，也讓用戶了解到數據變動的原因，降低了用戶的負面情緒和理解成本。更重要的是，不僅可以 能幫助用戶復盤業務情況，對業務起到指導作用，而且避免事故和損失的發生
但是兼容歷史數據也不是在所有場景都適用的，當我們涉及到的改動非常大的時候，比如業務發生巨大的變化導致原有表格欄位全部推翻重新設計時，就不建議採用上文的兼容方案，可以選擇新老數據交替過渡，原有的表格提供對老數據的支持，新建一個表格用於支持新欄位的展示，通過這種方式，完成從歷史存量業務到新業務的過渡；又比如整體項目需要重構，可以選擇數據遷移方案
現在當我們再次遇到歷史數據沖突需要兼容的情況時，可以判斷如何選擇了嗎？