I think a tree view would be the ideal component for what you’re describing. In this case, the runtime menu would be a poor choice because you have to manually build each entry. Thousands of objects in a tree hierarchy calls for a setup that will be dynamically defined by the database. We can visualize your data well without a tree, but the bigger red flag that goes off is about your data structure.
See this post about static versus dynamic schema layout, keeping in mind that a static schema is what you’re looking for. Also worth mentioning, our next upcoming feature, SQLTags, will do all the behind the scenes static schema database layout for you.
You’ll want to create the following tables: cities, organizations, sites, and equipment. You’ll probably want each piece of equipment to be a separate row in the table. If you introduce equipment of different types of equipment, create new tables by type. Make sure to add a column that points to their site. You’re going to want to make your data “taller” as opposed to “wider” for templatability. The more you expect the data at a given level to change, the more important it is to go with a rigid, static schema type approach. Ie, you’ll have 1000s of gizmos so they should be rows, but if you only have 3 cities you could work that in the designer and it wouldn’t be a big deal to manually add a 4th.
Getting back to a tree view, I can think of 2 obvious ways to populate it. The best would be with nice, static relational tables. Once you got it configured it would be entirely self defining from the database. The next best way is with a text path ie (c:\downloads\temp). In any case, the less predefined the structure is in your tables, the more you’ll necessarily have to manually make up for it when: creating, adding, or modifying your project.
I’ll post back with a few screenshots on how you could represent the data. For scalability, you’ll want to focus on the underlying data rather than what it looks like on the screen.