So i am creating a web service to predict future stock prices based on historical data for each stock and need to store the following information in a database:

  • Stock information: company name, ticker symbol, predicted price
  • For each tracked stock: historical data including daily high, daily low, closing price etc for every day dating back to 1-5 years.
  • User information: username, password, email, phone number, (the usual)
  • User tracked stocks: users can pick and choose stocks to be later alerted predictions of via email or phone.

The set of stocks that prediction will be made on will not be predefined and thus there should be a quick way of being able to add and remove stocks and consequently add/remove all data (as stated above) connected to them. My approach to designing is the following:

Table: Stocks

| ID  |  Company  |  ticker  |  industry  |  Sector  |  Prediction |

Table: HistoricalPrices

| StockID(using stock ID from above)  |  Date  |  High  |  Low  |  Closing |

Table: Users

| ID  |  Username  |  Password  |  PhoneNumber  |

Table: TrackedStock

| UserID  |  StockID |

Is there a better way at optimizing this organization? As far as queries are concerned the majority will be done on the historical data, for each stock one at a time. (Please excuse any security issues such as passwords being salted and hashed as the purpose of the question is on organization)

Was it helpful?


Simply said: No. THough you may want to add the colume to the historical prices.

What you may also want is to have a market table and to use lookup tables for industry, sector, possibly prediction - which should possibly be (the prediction) in a separate table with... a date (so you can look back to past predictions).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow