The steps of developing an App - Part 3 - Data, Schema and Storage
Welcome to part 3 of the series where we're exploring the various steps of developing a software application. If you happened to miss any of the previous parts, you can check them out at the links below:
Part 1 - The spec
Part 2 - Making mocks
In this post we'll be looking at the data that our apps use and how that data is saved. As an example we're going to use the same Web-Resume project from the rest of the series.
Why is this important?
I'd wager that the purpose of about 99% of all applications in existence is to move, manipulate and respond to data of some kind. And probably about 60% to 70% of the functionality of those apps are simple CRUD (Create, Read, Update, Delete) operations. Sometimes an entire app can simply consist of a way to create, edit and display some specific type of data - CRM systems for example.
Even the apps that you'd normally not consider having anything to do with data in a classical sense. That Arduino project of yours takes in data from sensors and transforms that into some electrical output - or transmits the result to be used by another app as its input data.
![arduino-UNO.png](https://steemitimages.com/640x0/https://cdn.arduino.cc/homepage/images/arduino-UNO.png)
PC and console games uses tones of data. It will take in your keystrokes and mouse movements as input data, reads the data from image files and 3d models, has to save the game state and ultimately transforms all of that data into the pixel data on your screen.
Data is literally everywhere and takes on many forms. The demand for professional and competent data scientists just keeps growing every single day - just type in "Data Science Demand" in any search engine, or you can read this article.
Having at least a basic understanding of how data is stored, manipulated and moved is critical for any software developer. If you can't grasp the basics of handling data, you're going to have a very hard time developing anything more complicated than "Hello World!"
Hopefully most of what I just said will be obvious to you.
Where to begin
So the logical thing to do would be to try to figure out where the right place is to start. And once again we're going to be consulting the spec we defined in part 1. For the app we're developing, we're going to store three different types of information:
- User
- Section
- Entry
I derived this list by looking at the description of the first couple of lines on the specification:
Content
- The resume should be split up into different sections specified by the user
- A section consists of a title, default sort-order and entries
- A section could have either a single or multiple entries
- An entry could consist of text (including dates and numbers), an image or a data structure
- A user should be able to manually show/hide a section or entry
- The content should be formatted so that it could easily be printed
For now I'm only going to refer to the different types of data by the generic term stores, since we haven't determined what the best storage method will be yet.
It's all about relationships
What we should do next is try to derive how each piece of information relates to other pieces. There are a couple of types of ways that pieces of information can be related to each other:
No relationship - The two records have almost nothing in common. For example the temperature outside vs the color of my shirt
One-to-One relationship - this usually means we're looking at the same thing from different perspectives. For example we could store employee information and manager information in different places, but a specific manager will likely have a record in both the manager store as well as the employee store.
One-to-many - This type of relationship is generally used to describe ownership of one entity by another entity. An example of this would be if we had a store of temperature sensors and a store of temperature measurements. Each sensor record will be the owner of several measurement records.
Many-to-Many relationships - This is usually the most difficult type of data relationship to grasp, but I'll try my best to explain it. To me personally it is useful to think about many-to-many relationships as different groupings of elements, or another way of stating it would be that this type of relationship describes a way for elements to be grouped together. It's probably best shown in an example. Lets assume we have a store for different student organisations on a campus and another store for the individual students. Each student can belong to multiple organisations, and each organisation (hopefully) has multiple students as members.
Now that we have that background. Let's try to figure out how the data in our app relates to one another. For now I don't think giving users the ability to have multiple resumes would be necessary, so any data associated with a resume can simply be stored with the user information. Each resume will have (own) potentially several sections, so we have a one-to-many relationship between the user store and the section store. Subsequently each section will potentially have multiple entries associated with it, so another one-to-many relationship. There's no real need that I can think of to have entries be shown in multiple sections, so no many-to-many relationships will be required in this app.
In summary we're going to have a structure like this:
What to store?
The final thing we are going to have to think about is what information we want to put in each of our stores. This is usually the most flexible part of the operation and will likely be changed and iterated a few times as we develop the app and when we decide to add features along the way. For a first iteration it should be ok to just wing it and make updates as we go along. What I've come up with for each data store was this:
User
- Identifier / username
- First name
- Last name
- Possibly contact information like an email address
- Password or other means of "Logging in in order to make edits to one's resume"
- Password recovery related fields
Section
- Title
- Default Sort Order
Entry
- Type
- Data
Notice that I wasn't very specific with the field names or types. Also notice that I didn't add the fields specifically related to the relationships between different stores. The reason for both of these is that we haven't concretely decided yet what technology we're going to use to store the data. We'll go through technology selection in the next article of this series...
Amazing!'
Upvoted and following you.
Thanks for post.
I wanted to write a small bot to find the best 'tippers' / on steem.
Is this along the lines your talking about here?
I would suggest you read the first two parts of the series.
I'm really more interested in showing the planning and design that goes into the development of any app. You could definitely use the information in this series to develop your bot, but it's not really like a tutorial that will show the exact coding steps.
Good luck with your project. I hope to read about it and possibly use it in the future.
Ok thanks will do.
I enjoyed reading your post , could you please just explain more the thrid part ? Thanks
You mean the "What to store" part?
Some of it was just me jotting down the fields that I think will be required to store for each of the data stores, the rest was me reading through the spec document that I developed in part 1 of this series, and then typing up all definite fields that I could identify.
The process of figuring out what to store is very app specific, and as I mentioned in the article as well, it will probably change as the app development progresses.
Hope that helps a bit.
Yes thank a lot , I will follow you , I'd like to learn more from you.
I realise that it has been several weeks since my previous post in this series. Life and work has been keeping me very busy lately.
Congratulations @hendrikcrause! You have completed some achievement on Steemit and have been rewarded with new badge(s) :
Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here
If you no longer want to receive notifications, reply to this comment with the word
STOP
Congratulations @hendrikcrause, this post is the second most rewarded post (based on pending payouts) in the last 12 hours written by a User account holder (accounts that hold between 0.1 and 1.0 Mega Vests). The total number of posts by User account holders during this period was 2546 and the total pending payments to posts in this category was $2246.80. To see the full list of highest paid posts across all accounts categories, click here.
If you do not wish to receive these messages in future, please reply stop to this comment.