Like many before me, I populated my app with filler data during my nascent development days. Since I was preoccupied with writing the business logic, it made sense to use fake stories and interviews. Plus, using hard-coded data allowed me to avoid a painful truth—databases terrified me.
Although I have accessed databases before, I had no idea how to set one up from scratch. Filler data was my buffer.
About six weeks into development, though—after I successfully connected my app to Evernote—I knew I needed to consider more critically how and where to store my app’s data. I finally accepted that I needed a database.
Before I go into detail on which database I used and why, I thought it might be helpful to recount some database basics.
What is a database?
A database is simply an ordered collection of data. In terms of mobile apps, databases separate the actual data from the business logic, simplifying the process of inputting, updating, and getting data. I won’t go into the nuances of database types today, but this post offers a good (if somewhat dense) explanation.
How do servers come into play?
A server is a computer that provides data to other computers. A database is traditionally hosted on a server. If you need to store data across devices, you will need to provide a server-side layer to “talk” to the database on the server. If client, server, local, and remote terminology still trip you up, I recommend this excellent guide by Fred Meyer.
Technically, you can (see AJAX), but generally speaking, it’s not secure or good practice to interact with your database directly from the client. Server-side code should sit between the client and server.
In my next post, I will detail how I researched and eventually chose my database from the sea of options.