One spreadsheet table per “entity” (a set of things in the real world) is the norm in AppSheet:
Every entity that you define (Job, Employee, Building) should have its own table (or sheet) within the document that you are connecting to AppSheet.
Put more simply, it is often the case that a “view” (UX) will have it’s own table. I think this is good standard practice for beginners but there are potential drawbacks. When, for example, I built a flashcard app with a separate table for each “side” of the card, I found that I sometimes had to wait quite a while for the two tables to sync with each other before I could continue using the app. And, there were other problems that stemmed from separating the data into two separate tables.
Since then, I have rebuilt the app with a single table that contains all of the key data for every record and the multiple views that are needed are associated with separate slices. Restructuring the app in this way took some time but the result is good: I no longer need to wait for syncing (the app continues to function while data is synced in the background).
The slices function like tables (allowing me to limit certain actions to certain views, etc.) and their functionality goes way beyond merely “slicing” (selecting a subset of ) data. Apparently, I’m not alone in preferring to associate slices with views instead of directly attaching views to tables:
There are many others on the forum who seem to be following this approach. I thought I’d write this little “tip” because I think the “Multiple tables vs. Single table + multiple slices” question is a key one that needs to be addressed fairly early in the app design process but doesn’t seem to be addressed yet in the official AppSheet documentation.