AppSheet enables you to create apps from your data. To get the most out of AppSheet, it helps to organize your data in an app-friendly way. Once you understand the basic concepts described in this topic, your data will be easier to manage and your apps will be more powerful.
Watch how to prepare your Google Sheets for use with AppSheet.
See also: Best practices with Sheets and AppSheet
Data is made up of records
A record is stored as a single row in your spreadsheet. It is an individual piece of data in your app, and might describe an individual customer, specific job site, or single product.
What we’ll want to do is keep each type of record separate from the others. To do that, each type of record should have its own table.
Tables are collections of records
A table is a collection of records of the same type. You might have a Customers table (like below), a Job Sites table, or a Products table. Think of tables as simulating things in the real world: people, objects, locations, events, etc.
Columns are the attributes of records
The rows in each table share the same set of columns. These columns are the attributes that describe the records: fields like
ID, and so on.
Each row is going to have its own values for each column, but the overall column structure determines the parameters and requirements of the table as a whole.
Think of a table like a form. A form asks the same set of questions of everyone who fills it out, but everyone has different answers. If you were making a table out of this form, each question would be a column, and each person’s answers would be in their own row.
How data changes
The row data within that table is what changes. As you use your app, you might add a new Customer, change the address of an existing Customer, or remove an old Customer. In fact, almost everything an app does is done by adding, updating, and deleting rows. But the column structure remains the same.
Get Started with Your Data
What Are the Tables?
The first thing to do is figure out what tables you need. You'll probably have several tables, since you'll have different questions of different types of data.
A good way to create tables is to create a single spreadsheet for the app, then add a worksheet for each table. Name the worksheet after the kind of records the table contains, such as
For instance, a library app that keeps track of books would probably need a table of
Books and a table of
Next, figure out the columns for each table. What information is needed for each record? What questions need to be asked?
In this library app, the
Book table will have columns for
Copyright date. The
Checkouts table will have columns for
Patron name, and patron
Be smart: Don’t repeat!
If you have a set of columns whose values will be repeated across many rows, you might want to take those columns and put them in their own table.
These column sets usually describe a person or place related to the current row. But imagine you had to update that information. You’d have to change it in every single related row, possibly making mistakes along the way.
It would be much easier to keep that information in one place. Fortunately, AppSheet lets you reference rows from other rows, which we’ll get to in the next section.
Let's create a new table,
Patrons, that will have the columns
Check Out row to which they're attached.
Give each row a unique identity
It’s important that each row can be uniquely identified. One of the columns should be a unique identifier, or primary key, that has a different value for each row.
Names and addresses stick out as obvious choices, but they aren’t always the best choice. Multiple people can have the same name, and addresses can change--that’s the reason you see seemingly random customer IDs and order numbers.
It’s not a bad idea to follow suit and give every table an ID column.
Patrons table has a
ID column as its primary key. That way, if I have two patrons named Alex Green, they won’t accidentally check out books on each other’s accounts.
Check Out will each get an ID column as their primary keys, too.
Tables, like spreadsheets, can only have one value per cell. You can’t pack in a whole list of records. For example, you might want to have a
Cats column, but since you can’t list multiple cats in a single spreadsheet cell, you’ll need a workaround.
At first, you might think a good solution is to use multiple columns:
Cat 3, and so on. But then you have a fixed number of books, and it can be hard to add new columns later.
A better solution is to create a new table. It may seem silly to create an entire table if all you want is a single piece of information in each row, but this option is much more flexible. You can connect rows in this new table to rows in other tables using reference columns.
Relationships between records
If you have multiple tables, you probably want to connect them in some way. A row in one table will have a reference to a row in another table, or you might want to have a list of related rows. These relationships are created using a special type of column called a reference, or
Ref for short.
Ref column takes a row’s primary key as its value. If you name the column something like
Book, AppSheet will automatically figure out it should contain a key to some row in the
Books table. Then in the app, you’ll be able to link directly from a row to its related row and back again.
Check Out table should have a
Book column instead of the old
Book Name column. That way, when you look at a
Check Out row, it will have a link to the book. Similarly, you can give it a
Patron column so it can reference rows in the
If you want to create a list of related rows, you’re in luck! AppSheet will automatically create a list of related rows.
If you want a record in my
Books table to have a list of reviews, you need to reference the book from each
Review record. Then when you look at a book in your app, you’ll see a list of related reviews.
Next, add a
Reviews table. It’s going to have columns for
Star Rating, and
Comments. You don't need to add anything to the
Books table: you'll see links to related
Reviewer rows when you look at a book in the app.
If you want two tables whose records each contains a list of records in the other table, you have hit upon a slightly more advanced topic. You can learn how to do this, and many other things besides, from a more general guide to data modeling or database design. The following aren't AppSheet-specific, but the same principles apply:
Put data in your spreadsheet
Now that you know how to organize your data, we have a few tips for how to set up your spreadsheet. See 5 Tips for Building Better Spreadsheets for your AppSheet Mobile Apps.
When you have data in your spreadsheet, make sure your column headers are bold so AppSheet will recognize them as headers.
Notice how those columns also have clear and specific names. This is much more helpful for you than naming your columns
Make sure that the data type format is consistent through each cell in the column.
New data should be added as new rows. AppSheet can only interpret new data as a row; if you add it as a column, it won't work. In the bigger picture, every record should be a column, rather than a row.
Bottom line: make sure that AppSheet reads a single table as your main source of information. Avoid using unstructured data, multi-format columns, or data outside of a table.