How To Design Your App’s Database

Written by Reinder de Vries on February 4 2018 in App Development

How To Design Your App’s Database

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 article 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.

Ready? Let’s go.

  1. App Database Tools: Relational or No-SQL?
  2. How To Define Database Objects & Properties
  3. How To Define Database Relationships
  4. Further Reading

App Database Tools: Relational or No-SQL?

When it comes to designing a database for your app, you can define three 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. 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 article, 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.

For the sake of simplicity I’m assuming that your local app database uses the same schema as your cloud-based back-end, which is often the case.

Learn how to build iOS apps

Get started with iOS 13 and Swift 5

Sign up for my iOS development course, and learn how to build great iOS 13 apps with Swift 5 and Xcode 11.

How To Define Database Objects & Properties

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

We’ll design three objects:

  • A Post that stores information for a social media post, like some text, a photo, and an array of likes
  • A User that stores information for a user, like username, password, and posts the user has created
  • 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 over 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?

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. So, 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. 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?

How To Define Database Relationships

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 three 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.

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.

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.

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.

Further Reading

And that’s all there is to it! Good luck designing your app’s database. If you have questions, please leave a comment.

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?

Want to learn more? Check out these resources:

Enjoyed this article? Please share it!

Reinder de Vries

Reinder de Vries

Reinder de Vries is a professional iOS developer. He teaches app developers how to build their own apps at Since 2009 he has developed a few dozen apps for iOS, worked for global brands and lead development at several startups. When he’s not coding, he enjoys strong espresso and traveling.