Depends on the type of data you want to to persist. Relational databases arenât always the way to go. If you're persisting simple trade data across a few tables then itâs pretty clear â stick em in a relational database and be done with it.
However persisting time series data is a whole...
âPocketChangeâ thank you again for the information.
Based on what youâve said my reasons for exclusively using limit orders may be flawed. Let me explain why - Iâm using limit orders to guarantee execution price. This is because by the time my system gets a tradable signal from the...
PocketChange (and all) many thanks for your contribution. It all makes sense and is a real eye opener- this discussion has led me to another level.
I've now written a quick n dirty (will fix up later) data engine which captures and stores real time Level II DOM data. This essentially gives me...
Thank you for all your replies. I have a question related to the relationship between the current bid/ask and the execution price.
To put it simply, if I placed a market order to buy would this get executed at the bid price at that time (visa versa for sell and ask)?
AND/OR
Can I...
I see. So if I place an order to BUY 10, and one counterparty fills size=5 @ 99.00 and another fills size=5 @ 99.00 - We would see two trades each with size=5 ?
Thank you for the replies. I think the âtrade through the priceâ approach is pretty good, since you can be certain that an order at that price would have been executed.
However, this raises another question which is perplexing me (perhaps itâs due to my misunderstanding of how markets...
Iâm currently writing a back-testing engine in Java which uses data captured from Eurex (via IB)
I have a couple of questions as to how I should model trades / executions,
1) Should I use the historical bid and ask values and assume that if the mid touches my requested order price an...