search

silahian / VisualHFT

VisualHFT is a cutting-edge GUI platform for market analysis, focusing on real-time visualization of market microstructure. Built with WPF & C#, it displays key metrics like Limit Order Book dynamics and execution quality. Its modular design ensures adaptability for developers and traders, enabling tailored analytical solutions.
Apache License 2.0
752 stars 152 forks source link

Consider using SQLite for the database #15

Closed drusteeby closed 9 months ago

drusteeby commented 1 year ago

SQLLite would allow the database to be stored as a local file and not require installation of any SQL server programs. More investigation required.

eabase commented 1 year ago

I was initially thinking about this, but AFAICR there are some MS SQL specific items, that I did not know how to replicate. Noting that I am in no way a MS SQL expert, but know SQLite3 very well. Another cool thing about SQLite is that it can be run completely in memory.

silahian commented 1 year ago

Thanks for the suggestion. Initially, this system was designed to run inside a corporation infrastructure, so MS SQL Server was used. But we always had in mind to ideally, make it provider-independent. So, if we can make that happen would be the best scenario. Where we can choose from different database providers.

What do you guys think?

drusteeby commented 1 year ago

I am not an expert in either SQLLite or MS SQL server so I'm using this as a learning experience.

What I do know is that a corporation is likely to be very hesitatnt to hook up a random project to their database server without thorough vetting. Another point is removing the requirement to install a SQL Server will make it much easier for new people to engage with the project.

silahian commented 1 year ago

Yes, I agree that MS SQL will be a high friction point. I would like to brainstorm around using entity framework (EF) and allow any type DB As far as I know, "EF Core" (we are using just EF) supports seamless integration with databases like: MS SQL Server, MySQL, SQLite, PostgreSQL and more.

Having all that, users can choose any db engine

ramateur commented 1 year ago

Is there any decision about db interface? EF core seems to be a suitable framework.

silahian commented 1 year ago

yes, this has changed. For now, the database access has been moved and encapsulated into the MSSQLServerTradesRetriever class. However, since the plugin architecture feature was added, I will move the whole class into an external plugin. So, users will be able to choose how to get "trades" and "positions", which was the reason why we held in DBs.

This will allow us to take out any dependency on databases in the main project.

ramateur commented 1 year ago

So, are all dataretrivers will be realized as plugins? And what about strategy interface? Especially external strategies written with python or c for example.

HereticSK commented 1 year ago

+1. It would be great if this can integrate with other language than C#

silahian commented 1 year ago

So, are all dataretrivers will be realized as plugins?

YES

The strategy interface will be also designed as a plugin, but this time as a UI plugin. I need to think about how exactly. I'm open to new ideas :)

ramateur commented 1 year ago

I have an idea of a strategy as a blackbox, which receives configuration then gets market data and sends signals (buy, sell, hold, etc.)

silahian commented 9 months ago

I'm closing this, since we are not dependent on DB any more. In case anyone needs a database, it could be added as a plug-in instead.