MySQL optimization - more tables vs more columns/rows
One table.  Period.  Full-stop.
A general rule is not to have multiple &quot;identical&quot; tables.  It is a maintenance problem, and it is likely to be slower.  (The common exception is SaaS, such as WordPress, where they simply live with lots of data bases with the 'same' 20 tables.)
&quot;35 datapoints ... dates&quot;  -- I'm confused.  Either you have information about a stock or you have daily prices going back years.  Are you saving only 5 weeks of data?  Or what do you mean?
5K rows in one table is &quot;tiny&quot; as datasets go.
Does this also have stock prices for each day?  With this, you get to millions or maybe billions of rows of about 6 columns.  Again, I strongly recommend a single table for all prices.  (Plus a table for all the tickers -- again 5K rows of 30 columns.)
I have dealt with such datasets, so ask away.  Or look around; I have answered questions like this in this forum and also in stackoverflow.com
The prices table would have something like
stock_id MEDIUMINT UNSIGNED -- 2 bytes
dy DATE  -- 3 bytes
open, high, low, close   -- see below

The prices get tricky.
FLOAT -- ~7 significant digits, 4 bytes; maybe good enough, might have roundoff
DECIMAL -- but how many decimal places; potentially bulky
INT -- not good enough
DOUBLE -- 8 bytes; overkill

Indexing will be important, but first, figure out what the inserts and selects are like.  These may be optimal:
PRIMARY KEY(stock_id, dy)
INDEX(dy, stock_id)

For one stock_id, there will be many rows.  Do not use 'many' columns for an &quot;array&quot;; that is very clumsy.  Perhaps your dates are &quot;quarterly&quot;, as in company reports, not &quot;daily&quot; as in stocks?
5000 companies with 8 years of quarterly reports, at one row each == 160K rows in the single table.  That's still a &quot;small&quot; table.
Plus another table with 5000 rows, one per company, with name, address, etc.  That is, attributes that don't change.
Yes, income, balance, cashflow, etc should be separate columns in the table.  Assuming those values come from a quarterly report, then they would be in the 160K-row table I discussed above.
A table with a few dozen columns and a few million rows is no problem (in general).  If you get to 100 columns or a billion rows, you may encounter non-trivial problems.