數據庫查詢服務框架

本來是爲了驗證前面的通訊框架，在不知不覺的2個月中，越寫越大。

既然寫了就簡單介紹下

數據庫查詢，主要是客戶端發送sql語句到服務端，服務端查詢完成之後將數據返回

        客戶端DBClientManager類中封裝了通常的sql查詢方法，按照c#的方式封裝的，只須要調用不一樣的方法則返回不一樣的數據；

通常的查詢均返回DBResult對象，裏面的Result字段對應返回數字，表結構DataTableJson對象；

固然也能夠返回sqldatareader對象，其原理是分步返回而已

構造的存儲結構是按照列存儲的方式，沒有按照簡單的object方式存儲，一個int轉成Object(或integer)存儲會形成很大空間浪費，具體緣由看java的存儲，因此優化了存儲；

    客戶端對外很簡單，就是獲取數據，也封裝了行列結構，像通常的操做，若是是c#程序員就會感受很熟悉，再也不復述。

   重點服務端，服務端除使用了表結構，行結構，列結構，還必須使用列映射；服務端使用封裝的DB操做，啓用鏈接池（本身封裝的），有一些默認配置；

DBDefaultConfig.json配置鏈接池（建議不要修改);DBConfig.json配置數據庫信息；鏈接池信息；

DBMapType.json設置數據庫列與java的類型;如今的設置基本夠了，程序中有一部分寫死了，通常映射，若是使用的數據庫不夠則添加映射;

Server.json 配置服務端IP,端口

 服務端根據客戶端的調用方法返回不一樣具體對象與數據，已經封裝

 通訊，封裝了通訊接口，能夠本身實現進行替換，程序中使用了udt,爲了適應程序，將udt源碼進行了必定修改，方便使用。通訊是動態調用的。

 這個通訊通過充分測試了的，應該直接使用。不清楚該通訊的請本身查詢

日誌使用了log4j

裏面也添加了客戶端向服務端傳送文件，測試腳本文件傳送。直接使用了udt中的文件發送

 數據傳遞，fastjason（阿里巴巴）,客戶端與服務端交互使用了json結構傳遞。

   大致上是這樣，就不詳細寫了，沒有什麼意義。裏面有不少。服務端還把數據庫操做分割成寫鏈接池與讀鏈接池。

   本來只是想寫個測試插件，符合前面的通訊框架，沒有想到越寫越多，越大。感受在寫的過程當中還能夠有不少開發的；一些想法驗證，就不想一一實現了，仍是收了，

數據庫的二進制等沒有驗證。因此最後粗暴的添加了一個插件接口DBPluginManager，任意添加。只要有固定的通訊與文件傳送，客戶端與服務端就職意了。

  使用數據庫postgresql測試。5個字段，字符串類型，每一個字段5個字符。全表查詢，15w行，使用時間6秒。客戶端與服務端同步。虛擬機測試。

 本程序全部配置使用的是json文件，json結構。

查詢以及使用的第三方包都傳到csdn,git.

選擇postgresql數據庫測試本來是想使用數據庫的同步功能，一個數據庫查詢，一個數據庫更新數據，同時備份了數據庫。具體你們有興趣就研究。

https://github.com/jinyuttt/DBRemote