Back to blog

How To Design Your App’s Database

Aasif Khan
By Aasif Khan | December 22, 2021 4:19 pm  | 5-min read

How do you design your app database in Swift? Every iOS app has a database these days, whether it’s locally or in the cloud.

Tools like Realm and Firebase take care of database setup and management, but how do you design the data that goes into the database?

In this tutorial I’ll walk you through the process of app database design. We look at database tools, how to structure your data, and how to create relationships.

Types of Mobile App Databases

When it comes to designing a database for your app, you can choose from 3 types of databases:

  • A relational database is structured to support relationships between pieces of information. Most relational databases use an SQL-like query language that allows you to filter and combine datasets in one result. Relational databases typically use a spreadsheet-like row-column format to save data. Examples include MySQL, sqlite, Parse Server and Realm.
  • A document database is similar to a relational database, except that it stores loosely formatted documents. This way you don’t have to strictly define your database structure before working with it. They often support relationships between objects, but can’t combine results in a so-called join query. Document-based databases are sometimes called No-SQL databases. Examples include MongoDB, Firebase Cloud Firestore and Elasticsearch.
  • A graph database uses graph structures with nodes, edges and properties to represent data. It typically structures objects by the relationships they have with other objects. Think of nodes as people in a group of friends, and relationships as the friendships between them. You can traverse the graph of friendships to quickly find out who knows who. Structuring this kind of data in a graph is more efficient than using a relational database. Examples include Neo4j and OrientDB.

Firebase’s Realtime Database fits in between a document-based database and a graph database. You can traverse the JSON-like database structure from any point in a path, and get the JSON document from that point in the graph. Realtime Database does not support advanced SQL-like queries, but it’s incredibly fast and scalable.

In this tutorial, we’ll only work with relational databases. Much of what you learn about relational databases can be applied to other types of app databases, but that doesn’t work the other way around.

Learning how to work with databases? If you’re new to databases, I recommend you start with learning good old plain SQL. This puts you close to the core principles of most database platforms and tools, such as queries, filtering with WHERE, and joins. You can find more sage advice about working with databases here.

The Schema: Defining Database Objects & Properties

Let’s say we are creating a mobile app database for a social media app like Facebook or Instagram.

We’ll design 3 objects:

  1. A Post that stores information for a social media post, like some text, a photo, and an array of likes
  2. A User that stores information for a user, like username, password, and posts the user has created
  3. A Like that stores information related to a “like” given to a post by a user

When you’re designing your database, simply start by looking through its mockups or UI designs. Every single user interface or app screen typically corresponds to a data object. Which types of data do you see? Start there.

In a social media app we probably have a timeline. The timeline shows posts from users, so that’s how we know we need a Post object. Users need to identify themselves, for logging in, and to organise posts. Now we know we need a User object. (More about likes, later.)

Some more examples:

  • An accounting app needs Invoice, InvoiceItem and Customer objects.
  • A sketching app needs Sketch, Collection and User objects.
  • A book review app needs Book, Review and User objects.

Once you know the types of objects you want to save in your app’s database, you can define the properties they have. The objects and properties together make up the so-called schema of your app database.

You’re most likely already familiar with the concept of “properties” – they are no different from Swift classes and Object-Oriented Programming.

We can define the properties of a Post object like this:

class Post {
var text: String
var image: URL
var user: User
var likes: [Like]

In the example above, we’ve defined a text property of type String and an image property of type URL. See how it’s just an ordinary Swift class with properties? Relational database objects are no different.

We’ll get to the user and likes properties next…

As an experiment, see if you can visualise the objects in a database as spreadsheet rows and their properties as spreadsheet columns. What if you “translate” your app database objects to a spreadsheet format? It’s a great way to kickstart your database design.

Defining Relationships Between Objects

In almost any app, database objects interact with each other. Posts are liked, users create posts, and comments are added to a post. When you design your app database these interactions are defined as relationships between objects.

There are 3 types of relationships:

  • A one-to-one relationship links one object with another object, such as User and AvatarImage. No user has the same avatar image, so they are linked one-on-one.
  • A one-to-many relationship links one object to many other objects, such as Post and Like. A post can have many likes, but one like can only connect to one post.
  • A many-to-many relationship links many objects to many other objects, such as Author and Book. An author can write many books, and many books can have the same authors.

Most relationships you define in your apps will be one-to-many. Let’s look at an example.

Here is the Post object again:

class Post {
var likes:[Like]
And this is the Like object:

class Like {
var post:Post

The Post object can have multiple likes, that’s why the likes property has the type “array of likes” or [Like]. Conversely, a single like can only be given to one post, evidenced by the property post on the Like object.

Interestingly, some many-to-many relationships are in fact just multiple one-to-many relationships! In a social media app, for example, many users can “follow” many other users. This is a many-to-many relationship, but it’s defined as two directional one-to-many relationships in your database. You commonly use a helper table/object to accomplish a many-to-many relation.

When User A follows User B, that User A is added to the followers property of User B. When User B follows back, it’s added to the followers property of User A. Conversely, when User A follows User B, the User A adds User B to its own following property (and vice versa).

By making these two one-to-many relationships, both users know who they are following and who follows them! You could say that a follower relationship is directional, i.e. when I follow you, that doesn’t mean you’re also following me back.

However, when you think of befriending someone it is different: when we’re friends, I am your friend, and you are my friend. This implies a many-to-many relationship.

Exciting, isn’t it? Make sure to keep the difference between one-to-many and many-to-many in mind, as it will save you a lot of headache in the future.

Most database tools define their own implementations of relationships, but the principles remain the same. In the example above we’ve used Swift arrays. Realm, for instance, uses the same format. Parse Server uses a so-called pointer. MySQL and SQL-like tools often use a simple unique ID or identifier key to reference connected objects.

Further Reading

And that’s all there is to it! Good luck designing your app’s database. To summarize, when you design your app database, this is what you do:

  1. Go over your app mockups and designs. What distinct data types can you identify?
  2. For each of those data types, what kinds of properties does it have?
  3. What are the relationships between different types of data? Are they one-to-one, one-to-many or many-to-many?

Aasif Khan

Head of SEO at Appy Pie

App Builder