<email@example.com>To: Ryan Turner , firstname.lastname@example.org
It's totally fine to have 100+ columns in a table. Column store means you only access the columns in a particular query, even if it is 30 or 40% of them.
You should start with all splayed tables (one per data frequency) since it doesn't sound like much data for kdb.
Your monthly and weekly tables could be sparse daily and filled or aj to the desired frequency. That would be more flexible than, say, forcing market cap to be weekly when really it changes daily and you might want to track it as such for some large cap stocks or something. Or maybe one company releases earnings annually so doesn't fit the monthly scheme you're assuming. You can easily convert between frequencies in kdb.
From: Ryan Turner
Sent: Tuesday, June 16, 2015 19:33
Reply To: email@example.com
Subject: [personal kdb+] Storing Price + Fundamental Data
I'm fairly new to databases. My current system uses hdf5 and is really starting to hit its limit.
I have roughly 15 years of data for 1000 securities. Each security has ~100 fields of varying frequency: