我正在嘗試構建一個應用程序,用戶將能夠在彼此之間爲遊戲傳輸令牌。現在,我有這樣的設計考慮數據庫模型驗證
- 每一方都將只有一個帳戶
- 複式記賬將借記/貸記存儲在交易表
- 的上市表用於用戶在 交易中發佈他們想要的金額,並且報價表存儲報價。
我想這個設計驗證爲正確的方式來設計我的數據庫。上市來自派對,會員或賬戶(如所列)?
最重要的是,我還有一個關於接受報價的問題,我如何在我的交易表中得到這個?
我爲此使用MySQL/PHP。
我正在嘗試構建一個應用程序,用戶將能夠在彼此之間爲遊戲傳輸令牌。現在,我有這樣的設計考慮數據庫模型驗證
我想這個設計驗證爲正確的方式來設計我的數據庫。上市來自派對,會員或賬戶(如所列)?
最重要的是,我還有一個關於接受報價的問題,我如何在我的交易表中得到這個?
我爲此使用MySQL/PHP。
鑑於應用程序流和數據關係的簡要概述,結構看起來很好。爲了回答您提供哪些優惠的問題,您需要問問自己您計劃使用哪種類型的權限?
這聽起來像「派對」更像是一個容器或實體,而不是一個用戶帳戶。所以你必須問自己,你打算如何工作。一方的任何成員是否可以代表該方接受/提出任何要約?如果確實如此,那麼只需將這些優惠鏈接到雙方並將交易存儲爲在雙方之間發生並列出發布/接受優惠的各方的成員。
否則,您可能希望將個人會員帳戶直接鏈接到其硬幣/優惠。雖然我看不出「派對」容器如何在該模型中有用。總而言之,如果您打算在「派對」級別完成交易和跟蹤,那麼您應該相應地關聯這些交易。否則,您可能會冒着對交易/硬幣數據的歧義消失,這會讓您有機會通過發佈優惠,離開該方並加入另一方,從而「竊取」或「移動」從一方到另一方的數據,然後取消要約,將「提供限制」中所持有的硬幣退還給他們當前的派對。