針對分佈式數據庫的解決方案/設計，具有時間同步的PK/FK解決方案

Question

這個問題更多的是關於代碼的體系結構和想法。

問題： 讓我們有一個存儲所有內容的後端主數據庫。 然後我們有一個前端本地數據庫（SQLLite或類似的），它只存儲用戶/設備的相關數據。

用戶可以在前端創建數據。但是，有幾個用戶可以同時創建同一種類型（即收據），如果我們使用簡單的int自動增量PK，則後端會發生衝突。

提出的解決方案是： 我們使用複合PK，其中所述PK組成： -autoincrement整數 -device ID -user ID

現在，logicaly，設備ID和用戶ID應該是FK到設備和用戶表，但是由於幾個原因，在每個前端設備上存儲所有設備/用戶不可行/不可行，所以FK使其成爲問題。

建議的解決方案是爲了省略FK請求並僅在後端檢查數據完整性，但說實話，我不確定風險/收益是否值得。

有沒有人對此有所瞭解和/或在部署後有一些經驗？ 你有什麼想法？ 非常感謝。

Answer 1

弗拉德，

我認爲你試圖解決的難題是：設備如何產生跨所有設備唯一標識符？過去對這個問題的回答是創建一個「全球唯一標識符」（GUID）或一個「通用唯一標識符」（UUID），它包含了唯一標識信息，如「設備ID」，「時間戳」和隨機數。這樣做的IETF標準可以在這裏找到：RFC4122。因此，大多數數據庫供應商至少提供了一個UUID（）或GUID（）SQL函數來返回這些唯一標識符之一。順便說一句，我不知道SQLLite是否提供了一個，但我知道SequelSphereDB確實提供了一個UUID（）函數。最終結果是您可以使用這些來爲行創建唯一的標識符。

因此，不是具有由數字，設備ID和用戶ID組成的組合主鍵，而是具有單個列CHAR（36），其存儲在行時在行進中生成的UUID創建。

UUID優點：

• 單柱
• 在客戶端生成，而不需要接觸的任何其它裝置
• 「保證」是唯一的，或者至少要比備用的可能性更是這樣。

UUID缺點：

• 柱儲存大：CHAR（38）。
• 與替代關鍵型單向發生器相比，發電速度較慢。