利用python解決mysql視圖導入導出依賴的問題

這篇文章主要給大家介紹了關于利用python解決mysql視圖導入導出依賴的問題，文中通過示例代碼介紹的非常詳細，對大家學習或者使用python具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧。
視圖

視圖是一個虛擬表（非真實存在），其本質是根據SQL語句獲取動態的數據集，并為其命名，用戶使用時只需使用名稱即可獲取結果集，并可以將其當作表來使用。

創建視圖

創建一個名稱為v1的視圖，其功能就是查詢color表中的所有數據    
CREATE VIEW v1 AS SELECT * FROM color;

查看視圖

使用視圖時，將其當作表進行操作即可，由于視圖是虛擬表，所以無法使用其對真實表進行創建、更新和刪除操作，僅能做查詢用。    
select * from v1; -- 等于執行SELECT * FROM color

輸出結果
    
+-----+--------+
| nid | title |
+-----+--------+
| 1 | red |
| 2 | yellow |
+-----+--------+
2 rows in set (0.00 sec)

修改視圖    
ALTER VIEW v1 AS SELECT * FROM color WHERE nid = 1;

刪除視圖    
DROP VIEW v1;

引用

navicat是mysql可視化工具中最棒的，但是，在處理視圖的導入導出方面，它是按照視圖名稱的字母順序來處理的，若視圖存在依賴，在導入過程中就會報錯。這個問題一直困繞我，一度因為我使用docker來部署mysql而繞過了這個問題。最近不得不直面這個問題，因此，寫了一個小工具來解決它。

整體思路

在mysql很容易查出所有視圖和其定義，因此可以寫一個視圖導出工具，存儲時對各視圖的保存位置進行調整，處理好它們之間的依賴關系，被依賴的放前面，這樣就解決了導入時的依賴問題。

獲取視圖信息

運行以下查詢語句，就能獲得該數據庫中所有視圖的信息。    
select * from information_schema.VIEWS where TABLE_SCHEMA = DatabaseName

查詢結果字段說明：

    TABLE_NAME ： 數所庫中視圖名稱
    VIEW_DEFINITION ： 視圖的定義代碼，只有查詢語句部分
    DEFINER ： 視圖定義（建立）者名稱
    SECURITY ： 安全級別

總之，所有視圖的信息都在這個表中保存，我要完成任務，只需要TABLE_NAME和VIEW_DEFINITION就可以了。

算法描述

    將查詢結果放到dict中，視圖名稱為key；視圖定義為value；
    編寫處理依賴關系的函數process_rely，輸入參數中的rely_old為保存所有視圖名稱的數組；返回參數為按依賴關系調整順序后的視圖名稱數組。之所以這樣做，是一開始考慮到，依賴關系復雜時，可能一次迭代處理不好，需要遞歸調用或多次調用。

process_rely函數算法描述：

    第一層循環，從rely_old中取一個視圖名稱

        第二層循環，從dict中取出一個鍵值

            若鍵值被第一層元素的定義所依賴

                若鍵值還不在結果數組中

                    若第一層元素不在結果數組中

                        追加鍵值到結果數組中

                    第一層元素在結果數組中

                        將鍵值插入到第一層元素前

                鍵值在結果數組中

                    第一層元素在結果數組中

                        查找各自在結果數組中的位置

                        若第一層元素在鍵值的后

                            將鍵值移動到第一層元素前

        第二層循環結束時，若第一層元素還不在結果集中

            將第一層元素追加到結果集中

    返回結果集

上面的說明，是按python代碼模式給出的。很幸運，算法一次就能將復雜的依賴關系處理好了。我在編寫的過程中，剛開始依賴算法不完善時，通過多次迭代也能處理好復雜的依賴關系。因此，堅定了必勝的信心，完成了這個任務。
完整代碼    
import pymysql
conn = pymysql.connect(host='172.17.0.1', port=3306, user='root',
      passwd='123456', db='database', charset='utf8mb4')
def process_rely(parmas={}, rely_old=[]):
 _rely = []
 _keys = list(parmas.keys())
 for k in rely_old:
  for bl in _keys:
   if str(parmas[k]).find(bl) > -1:
    if bl not in _rely:
     if k not in _rely:
      _rely.append(bl)
     else:
      i = _rely.index(k)
      _rely.insert(i, bl)
    else:
     if k in _rely:
      i = _rely.index(k)
      j = _rely.index(bl)
      if i < j:
       del _rely[j]
       _rely.insert(i, bl)
  if k not in _rely:
   _rely.append(k)
 return _rely
cur = conn.cursor()
cur.execute('select TABLE_NAME, VIEW_DEFINITION from information_schema.VIEWS where TABLE_SCHEMA = %s ', 'database')
rs = cur.fetchall()
cur.close()
conn.close()
ps = {}
for al in rs:
 ps['`' + al[0] + '`'] = al[1]
rely = process_rely(ps, list(ps.keys()))
# rely = process_rely(ps, rely1)
file_object = open('view.sql', 'w')
for al in rely:
 file_object.write('DROP VIEW IF EXISTS ' + al + ';\n')
 file_object.write('CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`%` SQL SECURITY DEFINER VIEW ' + al +
      ' AS ' + ps[al] + ';\n\n')
file_object.close()

小結

思路要清晰，代碼要一步步的向最終目標靠近，積跬步以至千里。在做這個工具時，一開始覺得很麻煩，依賴關系若是深層次的，可能一次處理不好，正因為采用的迭代的思想，最后才完成了一次迭代解決問題的完美結局。