Question

I’m creating a database schema for storing historical stock data. I currently have a schema as show below.

My requirements are to store “bar data” (date, open, high, low, close volume) for multiple stock symbols. Each symbol might also have multiple timeframes (e.g. Google Weekly bars and Google Daily bars).

My current schema puts the bulk of the data is in the OHLCV table. I’m far from a database expert and am curious if this is too naive. Constructive input is very welcome.

CREATE TABLE Exchange (exchange TEXT UNIQUE NOT NULL);

CREATE TABLE Symbol (symbol TEXT UNIQUE NOT NULL, exchangeID INTEGER NOT NULL);

CREATE TABLE Timeframe (timeframe TEXT NOT NULL, symbolID INTEGER NOT NULL);

CREATE TABLE OHLCV (date TEXT NOT NULL CHECK (date LIKE '____-__-__ __:__:__'),
    open REAL NOT NULL,
    high REAL NOT NULL,
    low REAL NOT NULL,
    close REAL NOT NULL,
    volume INTEGER NOT NULL,
    timeframeID INTEGER NOT NULL);

This means my queries currently go something like: Find the timeframeID for a given symbol/timeframe, then do a select on the OHLCV table where the timeframeID matches.

Answer 1

Well, on the positive side, you have the good sense to ask for input first. That puts you ahead of 90% of people unfamiliar with database design.

• There are no clear foreign key relationships. I take it timeframeID relates to symbolID?
• It’s unclear how you’d be able to find anything this way. Reading up on abovementioned foreign keys should improve your understanding tremendously with little effort.
• You’re storing timeframe data as TEXT. From a performance as well as a usability perspective, that’s a no-no.
• Your current scheme can’t accommodate stock splits, which will happen eventually. It’s better to add one further layer of indirection between the price data table and the Symbol
• open, high, low, close prices are better stored as decimal or currency types, or, preferably, as an INTEGER field with a separate INTEGER field storing the divisor, as the smallest price fraction (cents, eights of a dollar, etc.) allowed varies per exchange.
• Since you support multiple exchanges, you should support multiple currencies.

I apologise if all of this doesn’t seem too ‘constructive’, especially since I’m too sleepy right now to suggest a more usable alternative. I hope the above is enough to set you on your way.