Home/ Questions/Q 6682593
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T04:43:28+00:00

I’m trying to model a (very) simple share trading simulator in rails to play

  • 0

I’m trying to model a (very) simple share trading simulator in rails to play with 3.1 and try and learn more about web backend stuff as opposed to UX where I normally sit.

so lets say you’ve got 

Users (has many transactions)
Transactions (belongs to users, companies)
Companies (has many transactions)

So a User buys a number of shares in a company, and that creates a transaction record with the quantity column reflecting the number of shares bought for that particular transaction, the share price at the time, and a status column indicating whether things were bought or sold. (For simplicities sake, and as this is a learning exercise, lets assume that 1 transaction contains only one buy OR sell event)

So lets say the user, for some reason, buys and sells all kinds of strange quantities of the same company.

He’ll end up with multiple transaction rows, which must be queried and summed in order to figure out

for each company

  • if he owns any shares in it at all
  • how much he owns (all buys – sells)
  • etc.

So my question is, is this model correct for this type of use? It seems cumbersome if I want to, for example, write a page indicating what the user owns. It means running all kinds of sums of to determine if owned, and amount owned. But maybe thats just how these things should be done? Or is there a better way?

Would it be better to maintain only one transaction representing ‘ownership’, and update the columns in it for each company ‘owned’ and then record individual transactions in a second, transaction_history table that is separated out and joined to transaction?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think your model structure is fine. If you want to simplify the current ownership of a user, then you could add an additional table to effectively cache this information. Perhaps add a OwnedShares model that references a user, a company, and the amount of shares owned.

    You could then use an “after_save” callback in the transactions model to update these OwnedShares.

    With this structure, reporting on current ownership for a User would be easy, but you don’t lose the transaction history.

    • 0