I would lean towards the second for your case here, but I'd look at the human side and think about reporting as well.
First, components are editable by the project admins, so, if you make use of versions or delegate the user maintenance to project admins, you might find they go adding/editing/deleting components
Second, components are multi-select. You can therefore say "issue belings to General, Business area 4 and business area 7". That might not be valid for you
Both of those are simple to fix - use a custom field instead. You can have a single-select, or multi-select, as appropriate, and only Jira system admins can maintain the list of options.
For the human and reporting side, think about how you'd like your people to work. If each business area has a team of people who rarely work in other areas, then I'd be strongly tempted to have a project per business area. But if it's more about tracking "who wants it" or "where it came from", and your workers are all working together and don't really care that much about business area, then you'll find a single project far more easy to handle. The business area field remains useful for reporting, but the workers might not be bothered about it.
For what it's worth, there's a project here with over 90,000 issues, generated over 5 years. The only problem we've got with volume is slightly slow searches sometimes, and the "closed" statistics makes everything else look silly because it's always 99.99%...
The Jira Marketing team is putting together an ebook on migrating to Data Center. We're looking for pro tips on how you staffed your project team and organized your Proof of Concept. Share yo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG