Let me use an explicit but hypothetical example to add an answer. It looks like a "Parent" is a News Topic or event of sorts, which can have individual News Stories. For example:
/News/Weather/Default.aspx
/News/Weather/SanDiegoRain/Default.aspx
So the requirement is to know or maybe render something related to "Weather" while on the "San Diego Rain" page?
Note: the folder paths do not need to be based on Structure Groups. If using the Content Delivery API, (custom) metadata or Taxonomy could relate the Components so that you can retrieve other Weather-related items from anything tagged Weather (Parent1).
If you can flatten the Structure, you could instead have:
/News/TopicA/Default.aspx
/News/TopicA/Story1.aspx
/News/TopicA/Story2.aspx
/News/TopicA/Story3.aspx
Then you can get the location of all the stories under Topic A based on Structure Group location. You can use a page link in template code to resolve it correctly as well.
Though the parent field would work, from an editorial perspective the CMS user already created these relationships with Structure Groups and Pages. They shouldn't need to add another link to further relate the child items to their parents (be careful with "child" and "parent" since these can be confused with BluePrinting). This also assumes there's only a one-to-many relationship between the News Topics and Stories ("parent" and "children"). What happens for stories that belong to multiple "parents?"
Technically, C# TBBs don't go on pages (they can go on Page Templates). If not handled by the Page Template you might have a "dummy" Component Presentation that editors place on the page to add some type of in-page navigational element. The Component might be called "Section (SG) Nav" or similar.
If you do use Component links, consider flipping or otherwise changing the requirement. For example:
- The "parent" component links to its "children" -- this creates a "related links" type of relationship.
- Tag Components with topics (Keywords) so you can find related items regardless of Structure.
I'd suspect Taxonomy might be the better fit for the requirements here, which would be easier for editors creating the relationships, developers working with the requirement (which might evolve), and for visitors finding related content.