sam028 

I'm not sure it's very useful to have different databases, different tables are enough IMHO. The good question is more: what would be the tables structure. On my side I'm working on something similar with a single database and a table per bar type (tick/minute/day). I'm not sure it's the best option on performance point of view, as the tick table is going to be very very large, but on a "logical" point of view I don't like the idea of having a distinct table per symbol.

We are on the same page...
I have created a DB with 3 tables and I will run a test for a couple days / weeks to see what this gives
I can already see the first quotes rolling live into my DB

sam028 

I'm not sure it's very useful to have different databases, different tables are enough IMHO. The good question is more: what would be the tables structure. On my side I'm working on something similar with a single database and a table per bar type (tick/minute/day). I'm not sure it's the best option on performance point of view, as the tick table is going to be very very large, but on a "logical" point of view I don't like the idea of having a distinct table per symbol.

It made the most sense to have the table name be the ticker. In my case, I am capturing >5000 tickers, so some of them are reserved words like KEY and some contain special characters like TICK.Z. So be sure you are using proper backtick syntax.

Anyway, one database for daily, minute, ticks, and l2 made the most sense for me, so I could keep the table name uniform across all of it.

And I definitely think you should have one table per symbol.

My comments are based on large data collection. If you are only doing it for a handful of symbols, or only for a few million records, then anything would work. I am dealing with massive amounts of data --- my server holds many times more tick data than IQFeed's does, for example. And I have it for ALL tickers (US).

Mike