As no_free_lunch mentioned, many ways to solve this.
key-value is the simplest. 3rd normal form is an overkill - it can result in too many joins as well. the use case indicated calculated values, there would be no need to update them. if there is a need to update (say a calculation was wrong), a new table can be created.
the only field that would need to be indexed would be the company name (from no_free_lunch's example) or instead a company_id that would participate in a join.
i am not sure as to how may listed companies are there for US markets. including international assuming 100K, and assuming 100 values need to be tracked per company, we are looking at 10 million rows to be indexed for read, which isn't a big deal at all. if it becomes a big deal, data can be easily sharded with simple strategies (table name "company_i" for all companies starting with "i") and so on.
many ways to do this.
the links from salesforce architecture provide good details about choices. many large systems (facebook, twitter, linkedin, google) have gone with schema-less designs where appropriate for a good reason. key-value is a schema-less design.