Database model verification

I开发者_运维百科 am trying to build an app where users will be able to transfer tokens for games between each other. Right now I have this design in mind

database design link

• Each party will only have one account
• Double entry accounting will store debit/credit in the transaction table
• The listing table is used for users to post the amount they want to trade and the offer table stores the offers.

I would like this design validated as the proper way to design my database. Should the listing come from the party, member, or account(as listed)?

On top of that I have another concern of once an offer is accepted how do I get this in my transaction table?

I am using MySQL / PHP for this.

---

Structure looks fine to me given the brief overview of the application flow and data relationships. In order to answer your question about who the offers should come from, you need to ask yourself what kind of permissions are you planning to use?

It sounds to me like the "party" is more of a container or entity than a user account. So you have to ask yourself how you intend for that to work. Can any member of a party accept/make any offer on behalf of the party? If so then sure, just link the offers to the parties and store the transaction as occurring between the two parties and list the member of each party who posted/accepted the offer.

Otherwise you may want to have the individual members accounts linked directly to their coins/offers. Though I can't see how the "party" container would be useful in that model. In short, though, if you intend to have the trades and tracking done on a "party" level, then you should associate the transactions accordingly. Otherwise you risk disambiguation of the transaction/coin data which would leave you with chances for people to "steal" or "move" data from one "party" to another by way of posting an offer, leaving the party and joining another, then cancelling the offer, returning the coins that were held in the "offer limbo" to their current party.