Use a separate model to store the feed entries as you suggest in your first idea. The design pattern your looking at is called polymorphic association pattern
Let's assume this new model is called Feed, following the polymorphic associaiton pattern you would use the columns: feedable_type and feedable_id (as apposed to your suggested column names model and associated_id)
I do have to admit that your problem is larger than the simple understanding of polymorphic associations, feeds are a major innovation of modern information design and entail many complex features including:
- Privacy
- Follow / Subscribe
- Filtering
- Merging
All this can become intensely more complicated depending on any of these attributes. And if you have to meet some non-functional requirements like scaling and performance the headache will quickly compound.
If you've ever built a Facebook application, it is quite enlightening to see how their feed publishing API works.
You will quickly notice that the separate model used to store the feed is quite unequipped to render the feed entries HTML, but loading the original model that is well equipped to render the HTML is database expensive. To solve this problem, I have the original model render the feed's HTML and I store this into the feed table.
Of course the implementation is even a little more complex than this. Like with Facebook, all feeds have 1 point in common (They come from people). So each feed entry has user_id (so to speak). Since we know all feeds have this data and can render the "who did it" portion of the news feed, we don't pre-render that part.
It's quite helpful to pre-render as much as possible that would be difficult to re-build from the feed model later, but delay pre-rendering when we are sure that component is ubiquitous and be tucked into our feed model.
Finally, studying open source projects is a good way to learn