雲是乙個概念，雲的設計也很寬泛；在雲同步中我想經常會遇到多裝置的問題。簡單來說就是使用者通過乙個賬戶連線到雲，而後在任意可支援的裝置上登陸同乙個賬戶能實現賬戶資料共享的目的。
in this，我將簡單示範一種雲端乙個賬戶多裝置同步的資料庫設計方案；該設計並不是最優，但我想也算是一種思路。
如果大家有更好的方法，歡迎一起交流~~
先來簡單說說需求；拿移動裝置來說：此時有多個移動裝置，我想要做的就是能把a裝置的資訊同步到b裝置，當b裝置有變更的時候也能同步回a裝置，同理能同步到c裝置。
再簡單點來說，就是在多個裝置上能保證資料統一性。
當然也可以這樣：
這裡的雲之所以框起來，是因為「雲「對使用者而言是不可見的；使用者認為的只是裝置與裝置可以相互同步而已。
純手工雲朵～～
一般來說同步資料有以下情況（假設現在是兩台裝置）：
a新增一條資料，此時b應該得到新增的資料
a修改一條資料，此時b應該同樣修改該資料
a刪除一條資料，此時b應該把資料刪除
a修改一條資料，b同時修改該資料，a先同步，此時b應該保留修改狀態，並同步b狀態到雲，隨後a同步為b的狀態。（當然也可以先同步優先的法則）
嗯，暫時想到這麼多，也就是增刪改~
一休大師發功了；
在這裡需要好好想想，我們來梳理一下。
a刪除了一條資料，此時進行同步，那麼雲中的資料應該如何變化？是刪除？還是加上刪除標識？還是其他？
a此時刪除，那麼我把雲中該資料移動到臨時記錄表中。我其實並不想說這麼多，但是僅僅只是圖我想可能說不明白；下面來看看圖。
說的差不多了，該進行表的具體設計了；當然由於篇幅等等，表中的字段都盡量最少；字段主鍵也就用int代替了；能理清關係就好。
賬戶表，同步資料當然最好還是有個賬戶好點的吧。該錶主要用於記錄賬戶的資訊，當然應該還包括密碼啊什麼的，不過這都不是重點。
字段：裝置表，乙個賬戶可以在多個裝置上登陸，而每台裝置應該具備唯一標示；無論改裝置登陸多少次但是其標示永遠都是唯一，這個取決於具體的裝置，這裡就用sn來代替了。
當然裝置表與賬戶的關係是：多對一關係；乙個賬戶可以在多個裝置登陸。
字段：記錄表，這裡就用該錶代替具體需要進行同步的資料了。
該錶與賬戶的關係是：多對一 ；乙個賬戶可以有無數的記錄。
該錶與裝置的關係是：多對多；不過這裡可不必有該關係。
字段：刪除資料臨時儲存表；當刪除一條資料時如有其他裝置可能（可能並不是絕對）儲存該資料時，應該把資料標示儲存到該錶；而當可能儲存改資料的裝置同步時可從該表中獲取到需要刪除的記錄。
當裝置x獲取資料標示後，刪除該表中該資料中x裝置的值，如果沒有任何裝置持有該資料那麼刪除該資料。
該錶與賬戶的關係是：多對一；但該關係不能直接關係而要通過裝置進行關聯。
該錶與裝置的關係是：多對多；這裡需要持有該關係，裝置通過關係可以直接查詢是否有需要刪除的資料；當獲取後裝置與刪除資料的關係斷開；如資料未與任何裝置有關係（所有裝置都已經刪除了該資料）那麼刪除該資料。
字段：
按照上面的規則，最後的圖大約是這樣的：
開源庫：github.com/qiujuer/genius-android
開源庫：github.com/qiujuer/blink
—— 學之開源，用於開源；初學者的心態，與君共勉！
基於Powerdesigner 的資料庫設計流程
軟體環境 powerdesigner version 15.1.0.2850，sqlserver 2005 研究意義 在軟體設計過程中需要對資料庫建模，需要用概念模型與使用者交流 資料庫的字段 資料庫的建設還要盡量避免重複的勞動，這就要用到建模工具。問題出現了，powerdesigner 中的 cd...
資料庫之間的資料同步
資料庫之間的資料同步有以下幾種情況 第一種是在非業務工作時同構資料庫之間資料同步，這種情況下，只有存量資料庫。只需要將源庫中的資料檔案拷貝的目標庫，目標庫載入資料檔案即可。第二種是在非業務工作時異構資料庫之間的資料同步，這種情況 下，只有存量資料庫。需要將源庫中的資料以sql資料形式匯出，然後載入到...
資料庫表多對多的設計
先上問題！現在有a b c三張表，a和b是一對多的關係，b和c是一對一的關係，c和b是一對多的關係，a和c是多對多的關係。問題 是否設計第四張表專門存放a b c的關係，還是把關係維護在b表中？原則 首先在資料庫中不建議建立三維關係。其實就是說一張表 關係表 不要維繫三個模型的的關係 設計思路er圖...