I appreciate your acknowledging and thinking so carefully about this issue.
I began using Airtable only a few weeks ago. I was immediately impressed with the way Airtable combines relational database structure and logic with ease of use and a simple, attractive UI. My developer coworker might eventually apply your API for data integration with external systems.
My use cases relate to our small non-profit organization built around a Web site for which discrete articles comprise the primary content. The relevant information associated with those articles tends not to change rapidly over time, but it can and will change.
For us, an article list would be one of the tables with potentially mutable data and with the greatest potential to be relevant across multiple Bases. Other such tables include a list of topics to which articles are assigned, and lists of people and entities with whom we interact in some way or otherwise wish to track relationships with.
I’d rather update such general-use information only once, in one virtual “place” – after all, that’s one of the fundamental benefits that a relational database system should offer. However, the cumulative number of standalone tables I envision for my Base ideas – if constrained to a single Base – would be very cumbersome for me to work with and overwhelming for any of my potential coworker clients to be exposed to. In addition, none of those individual clients would benefit from access to more than a fraction of the information that I think would be valuable to our organization as a whole.
I envision a natural, self-evident distribution of this information across multiple Bases, with information on articles, topics, people and entities, et cetera, each available across a substantial subset of those Bases.
Regarding your three points:
At this time, granular permissioning – in terms of access/visibility control – is a negligible interest and concern of ours for our current and prospective Airtable use.
I believe that each of the multiple Bases I envision should be suitable for data entry and online table/form viewing. While I suspect we might ultimately find use for some sort of “master” base functionality, that is speculative and would likely only provide tertiary value.
As suggested above, this IS a major concern. I confess that I’ve yet to make an effort to custom-design forms; I’ve only implemented a single customized Kanban view for one table in my first substantially fleshed-out Base. I may have yet to discover effective ways to hide (or at least mitigate) some of the “clutter” of the nearly 100 tables in that base. That said, the loading time consideration you mention definitely comes into play, particularly when Blocks are displayed in the right sidebar. Also, even for myself as a “designer”, I believe that the visual metaphor of separate Bases with small proportions of shared information will make my work easier conceptually and visually.
As I mentioned, I currently have minimal concern about granular permissions overall when it comes to access/visibility. Regarding “How would linking across bases work with editing?”, I suspect it would be helpful as a designer to choose – on a case-by-case basis – whether or not someone can modify a table shared from “Base B” while within “Base A”. However, if that were a substantive roadblock to implementing inter-Base linking overall, I would gladly sacrifice that ability to hasten access to inter-Base linking.