This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
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.
A table can reference itself, so you can have a parent/child relationship using only one table. However, if I recall correctly, AppSheet doesn’t maintain the Related columns (with the REF_ROWS() app formula), so you’d have to add them yourself if you want them.
I’d need more specifics to form a qualified opinion, though just on the surface, you’re probably pushing the boundaries of what AppSheet is suitable for.
Agreed. Appsheet can handle a fairly large app I have that has two sets of many-to-many link tables, but querying through them can start to cause speed problems. That’s why I was interested in using one table. thx
Good luck! Reducing the number of tables in my app significantly improved the performance. Users no longer have to wait for 20 seconds or so for a sync to complete.
I tried to figure out this and manage to add refs slice to itself (one table) in this case I need only one ID. But how to add in one table more than one IDs, different ID for each slice?
In my app, I don’t use different keys for different slices. In fact, having the same keys is useful. However, if you add a new row, then you need a new key. Are you familiar with uniqueID()?
LinkedIn
Twitter
