Best way to set up database

I need to allow my Users to record a start and stop time for work that they do. When they have finished recording multiple start and stop times (within a single job), they can click a button to calculate total hours done.

The difficulty is how to store the multiple shifts and then retrieve them when the final button to calculate is pressed?

I am thinking to create a new database ‘Thing’ called shifts which will record the individual start and stop times within a job. Then have the following fields in the shiftsThing;

  • User
  • Job title

Or, should I create a new database ‘Thing’ called Job and have shifts within that?

1 Like

@darren.james7518

That’s how I would go about it. You can then use ‘user’ for privacy rules.

I’d probably have ‘Job’ as a separate data type too. You probably already do, but if not, that would make things easier than just having a job title on each shift.

@darren.james7518 if you haven’t seen the best practices from AirDev, it’s really insightful!

Thank you, but to clarify, should I make the main database Thing Job and have shifts within that - or, should I make the main database Thing shifts?

Thanks for link, I will check that out.

So the answer really depends on how many shifts there will be within a Job, but either way i’d have two data types “Job” & “Shifts”.

If 5 or below shifts within a job i would go with:
Data type: Job
field 1 : “Title” {text}
field 2: “Shifts” {list of shifts}
field 3: “User” {user} **
& any more fields relevant to the job

Data type: Shifts
field 1: “User” {user} **
field 2: “Start time” {date}
field 3: “End time” {date}
field 4: “Job” {job}

Field 4 is not required here, as you can reference the shifts from field 2 on each Job, and if you want to keep things minimal and quicker then do not include it. However, it can be useful to easily find the relevant job from a shift entry, it depends on how you intend to display the info on the page etc, and your personal preference.

If you have 5 or more shifts within a job, or there is potential for this (likely i assume) i would not list the shifts within each job, as this will slow things down. As the article explains bubble isn’t great at handling that. In that case i’d go with:

Data type: Job
field 1 : “Title” {text}
field 2: “User” {user} **
& any more fields relevant to the job

Data type: Shifts
field 1: “User” {user} **
field 2: “Start time” {date}
field 3: “End time” {date}
field 4: “Job” {job}

Here field 4 is required, so you can find the shifts related to each job.

** Regarding all the User fields. If I was trying to keep things streamlined, I would try to use the default bubble field “created by” instead of having another field for ‘User’ if this would be the same person. However, you couldn’t then have someone else create a “job” for an employee for example. Hopefully, that makes sense. The article explains it better than me!

1 Like

Thank you for your detailed explanation! I have opted for the solution above because it feels more intuitive to me.

It was interesting to read the article your recommended, they said something which helped me visualise things a bit more;

If you’re familiar with Excel, think of how your data would be represented in a spreadsheet. In the Excel example, each tab represents a data type, each column represents a data field, and each row represents a thing.

I will continue my app and see how I get on! Thank you again!

1 Like

I’m having some trouble saving a new shift. The button to save a shift won’t let me reference the Job title. Wondered if you can see where I am going wrong?

Here’s the database settings for Job

Here’s the database settings for Shifts

Also, do you think I will need to name the Shifts so I can display them sequentially, as below?

name shifts

The ‘Job title’ field on your ‘Shifts’ datatype is of type ‘Job’, so must be a Job.

In your workflow you’re trying to set it as a text (the Job’s Title) - hence the mismatch error.

You need to select an actual Job for the ‘Job Title’ field, so just remove the last ‘Title’ from the expression.

On a side note, it seems a bit confusing to name your ‘Job’ field ‘Job Title’ when it’s actually a Job (it would confuse me anyway), especially when the Job datatype itself has a field called ‘Title’.

I’d recommend trying to be as logical as possible with your naming conventions as it can definitely help keep things clear when you’re working - the more the expressions read like actual English the easier they are to follow (certainly for me).

1 Like

Thanks Adam, I have changed the ‘Job title’ field to ‘Job’.

The create a shift page uses data passed from the previous page where the job is set up, so in my workflow for created a shift I have now specifiedJob = Current page job but the DB shows a long string of numbers as the Job title instead of the actual title?

The Job Title (text field)? Or the Job (linked object field)? (maybe post a screenshot to clarify)

Unless you’re setting the Job Title field to be the Job’s unique ID then that shouldn’t be happening.

I suspect you mean that you’re seeing the unique ID of the Job (that’s the default way to display data the DB view) in the Job field of your Shift datatype?.

You can change which field is displayed for a specific datatype in the DB App Data tab by clicking the Primary Fields button in the DB App Data Tab.

The way it’s set up is that a User creates a job which includes a title (that saves correctly to DB) and then they go to a new page to start a ‘timer’ to record the Shift for that job. But, the ‘start timer’ button won’t save the Job title to the DB.

set job

What I see in the DB is this;

Screenshot 2021-09-24 102900

Yeah that’s the Unique ID of the Job.

You can change the specific field shown in the App Data Tab for each Datatype as I said by clicking the Primary Fields Button and setting the primary view field for each datatype (the primary view field is purely for display purposes in your DB tab, and also for exporting data, and has no consequence other than that).