Holding duration

Hi I am trying to make something similar to stock portforlio
I have implemented buy and sell buttons. So when sell button is clicked it will record profit/loss and date and email in a different glide table and deletes the current row.
So what I want to achieve now is to record how long a user held that position when he sells the position.

Any idea or tip would be much appreciated.

Date difference doesnt seem to work.

Thank you

@glide, the question is about the time difference (duration) between two DateTime values. In the question, position refers to a position when investing or trading, not a geographical position.

Could you try answering again?

1 Like

This is an experimental reply from a bot. Please like it if it’s correct.

Yes, of course. You can use the Date Difference plugin to calculate the difference between two DateTime values. This plugin will give you the number of days, weeks, months, or years between the two dates. You can also set the accuracy to ‘longterm’ for a pedantic 400-year calendar. Glide • Date Difference column

1 Like

Yes it refers to investing or trading. So a user adds his stock to my portfolio app, it will be recorded with his email and date and when he clicks ‘sell’ button profits or loss and email and date will be recorded in another glide table.

I think I would have a Stocks table with general information about a stock/security and then a separate Orders/Ledger table where I would store buy and sell orders.

2 Likes

Continuing from Nathanael’s idea, would you store buy and sell orders as 2 rows, or do you use just one row with “buying timestamp” and “selling timestamp” as different columns?

2 Likes

Hi, I am storing selling info in different table. Basically if a user clicks the button it triggers add row action in the transaction table and then delete this item action which deletes the current holding info in the ‘position’ table.

There are probably many viable options, though intuitively I feel you might be better off storing all of your buy and sell orders in one single table. Not that your approach would be wrong, but by “better off” I mean simpler, more intuitive, easier to maintain.

Thinh makes a good point: for one given position which is determined by a buy and sell, would you go for 2 rows (one for buy, one for sell) or 1 row (one buy column timestamp, one sell column timestamp)?

It probably depends on what you plan to do with the data: if you plan on displaying lists of orders and giving the ability to see the details of each order, then 1 row per order seems in order (pun intended). If you would need to do rollups and determine balances, I feel 2 rows per order (one row for buy, one row for sell) would make things easier.

From a data architecture perspective, I would be uncomfortable having 2 columns (one for buys, one for sells) to store data that is actually of the exact same nature. The only thing that differentiates a buy from a sell is a plus or minus sign, it makes sense to me to have all buy and sell values in one single column. My naive intuition is that a professional developer working on a portfolio/financial app would have a ledger-type approach and would allocate one row per order (so 2 rows per position), this approach feels the most versatile. Each order (row) would then have a unique OrderID (fine) and a PositionID which would be the same for the buy and sell orders of the position. One could relate a buy and a sell to get the position via this PositionID.

4 Likes

Thank you for the answer I will try out some options

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.