batman, db4o will easily keep up with what you want to use it for. Im doing real-time data storage at tick, bar, and daily levels at once (3 databases, on for each type) per symbol, and have not had any issues. Granted, I've never tried storing say 500 symbols in realtime, but I generally monitor about 30 markets or so, and never get any lag from the db. I have a sql background as well, and I will tell you that for me, speed of development was what set db40 apart for my needs. You dont have to worry about writing translation interfaces from your object to the data store, and it just works. You can write your queries just like you would in LINQ(Im assuming you have a .net background, but if not you can also use SODA queries to get the same results) and its all nicely typed. I dont have any interest in db40, Im just telling you it works well for me. Feel free to pm if you have more specific questions. loltrader, Its very easy to achieve 100,000 writes per second with simple objects in db40. If you dont have many levels to an object(say tick or bar data, which only have timestamps and a couple of values) db4o cranks through them with ease. You could download the open source and run a simple test with no optimization on the db, and be able to duplicate that performance in a few minutes.
dvelopment time isn't an issue - lets say i take a week or a month to make db in sql server when I can do it in 1 hour in db40.. but once built, it's done.. my db is very simple. just a table for each instrument as u said with historical prices and datetime stamps. assuming they are both built - which is better? there just seems more support etc for sql server. even for speed db40 isn't as good as some think it is (having looked over the net on the topic) so is the advantage only the development time of making the db itself?
Again, it really depends on your intent with the application. For my app, I had several requirements: 1) Needs to be fast as possible to both read and write tick data 2) Needs to be lightweight and zero maintenance to users 3) Needs to be able to grow as large as necessary For me, db4o gave me that where SQL CE didnt, and as a bonus I got quicker development time. Bottom line, it wont take you but an hour to prototype storing and retreiving your bar data with both SQL and db4o, so my best advice would be to just try them both and decide for yourself. That's what I did, and how I came to the conclusion I made. Good luck with your project.
thanks, you're right I'm going to play with it over the weekend and see how it really is to work with.. thanks for sharing your view again.
This is always such a funny discussion.. People debating alot about databases and programming languages. Without even concentrating me I have pulled a small application together that processes 40.000.000 ticks into 5 min bars and plotting those at a chart - all in about 5 seconds. Forget about the db and language, just start programming which reminds me of a good old saying "Stop thinking, start trading"