App Design: Multiple tables vs. Single table + multiple slices

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.



Today I learned about another advantage of using slices – they make it possible to reorder forms:


Am I right in thinking that if the app needs parent/child relationships, this can’t be done using one table?

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.

1 Like

Thx, that’s interesting. I think i’ll do a dummy app to get to grips with it.

I have an app with many-to-many relationships, between two tables, via a link table. This, I’m thinking, is a bridge too far for a single table?

1 Like

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.

1 Like

Thx. I’m definitely going to explore this.

1 Like