Table Design for my Database - mysql

I am in the process of designing a very simple system for keeping track of a shifts worked by the sales team. Although i'm still designing and not done yet, I later realized I left out one important detail that I'll get into.
Some quick background first:
Each shift consists of how long the shift was (hours worked), whether it was the morning, afternoon, or night shift (or some combination), how much in sales were made for that shift, and how many tips the person made that day. I also keep track of things like whether it was cash or credit tips you received for doing your job well.
So one extra thing that happens is the sales team gets paid by the hour. For reports and running totals I am currently just calculating your income for that shift as pay rate (from job Position table) multiplied by the hours you worked, but I forgot the fact they could get raises! This means that if you get a raise, your income would magically increase (historically speaking)! I might've been making $10 an hour last year, and now $15 an hour this year - So the reports would be wrong.
My initial thought was to simply add a new column in my 'shift' table called HourlyRate, and that would be whatever the current hourly rate was at that moment in time. $10, $15, etc. Then I can just use this rate when i'm performing calculations
Do you all think this is an acceptable solution? Would it be weird to have a few hundred rows of sales all with the exact same hourly rate column for the same sales worker?
Thanks so much for your help!

Related

How to create a table of "Not used time" in spotfire

User wants to see a report of when resources are NOT being used during the work week on average.
Available to me I have a reservations table along these lines:
table
Attached is the picture of how the user would like the data represented. example graph
I think my issue lays in getting the data in the right format, how can I take a reservations table and inverse it so to show all available time in-between two reservations.
I was able to get a Bar graph that showed the average availability of the days that the resource was booked, but it didn't consider days that there was no reservation information, it also did not account for situations where the user had booked for more then one day.
Have you tried making a calculated column?
This worked for me:
1440 - Sum([Duration]) OVER ([StartDateTime])
1440 is the amount of minutes in a day. It subtracts the total amount of 'busy' time in each day from the total minutes in the day.
It is then easy to make a bar chart from this column.
This worked in my testing, but it might run into issues if you put it into practice. Keep me updated!
Table with calculated column, and barchart.

How can I write a query to get a view count in a specific time frame with no timestamp?

I need to know how many times a page is viewed in a specific timeframe, say the last 30 days. In the database there is a PageViewCount field so every time the page is viewed, the PageViewCount increases, but there is no timestamp in the database of when this occurs.
I know there has to be a simple solution to this, but I am having a real hard time wrapping my brain around it.
As it is stated, it is impossible to query for such a value. Consider the following equivalent example: I have some coins, for a total of $3.50 and I don't track the movements of the coins. How much money did I had yesterday?
You should have a daily procedure that stores the current PageViewCount with the current date in another table and then simply query that table.

Limit range of trendline to the first couple of bars in clustered column chart

I'm trying to limit the trendline online to the first 2 bars of a clustered column chart.
The background being, say this is the 2nd week of January and I would like to show a trend between actual and forecasted hours. For the first two weeks of January where I have actual hours the trendline does a good job. However for the 2nd half of January, the trendline does not accurately reflect the trend as it only shows the forecasted hours not the actual hours.
In our business we forecast only the hardcore committed hours, typically 60% of the time dedicated to inflexible/predictable standard tasks. The rest, the actual hours are then added on top with variable, unforeseen tasks. Thus, I would like to make the trendline stop e.g. after the first 2 weeks, since I only have the actual hours/percentage of time spent for those 1st two weeks.
I have tried to achieve this by right clicking on the chart and clicking 'select data' but that does not work.
Any suggestions welcome!
Its not completely clear what you're trying to do. But maybe your just missing a simple point here:
Instead of displaying trendline on the forcast serie, you may just need to display it on the actuals serie. Here is a visual of the difference you would have with moving average:
... Remember, if it solves your issue, kindly approve this answer. You didn't do it for Zolvas answer which obviously solved your problem. It will also give points to you too.

Handling a "ledger" in MySQL and keeping track of the total balance

I have a sort of simple ledger in my app. I keep track of each balance adjustment i.e. deposit $10 into an account with $5 creates a new row containing the amount of $10 and the total of $15. The $15 number is the part I'm having a hard time figuring out how I should handle it.
I can do it totally app code side with my DB adapter by getting the last row's total and adding to the new amount and creating a new total_balance based on that. This, however, feels wrong to me for some reason. I feel like I should be able to do this logic all in MySQL somehow.
Something like "create a new record WHERE user_id='123' and the amount is +10" and it'd make a new record with 15 for the total_balance automatically.
Is this possible?

MySQL Database Structure For Employee Timeclock

I'm working on an app that is partly an employee time clock. It's not too complex but I want to make sure I head in the right direction the first time. I currently have this table structure:
id - int
employee_id - int (fk)
timestamp - mysql timestamp
event_code - int (1 for clock in, 0 for clock out)
I've got everything working where if their last event was a "clock in" they only see the "clock out" button and visa-versa.
My problem is that we will need to run a report that shows how many hours an employee has worked in a month and also total hours during the current fiscal year (Since June 1 of the current year).
Seems like I could store clock in and outs in the same record and maybe even calculate minutes worked between the two events and store that in a column called "worked". Then I would just need to get the sum of all that column for that employee to know how much time total.
Should I keep the structure I have, move to all on one row per pair of clock in and out events, or is there a better way that I'm totally missing?
I know human error is also a big issue for time clocks since people often forget to clock in or out and I'm not sure which structure can handle that easier.
Is MySQL Timestamp a good option or should I use UNIX Timestamp?
Thanks for any advise/direction.
Rich
I would go with two tables:
One table should be simple log of what events occurred, like your existing design.
The second table contains the calculated working hours. There are columns for the logged in and logged out times and perhaps also a third column with the time difference between them precalculated.
The point is that the calculation of how many hours an employee has worked is complicated, as you mention. Employees may complain that they worked longer hours than your program reports. In this case you want to have access to the original log of all events with no information loss so that you can see and debug exactly what happened. But this raw format is slow and difficult to work with in SQL so for reporting purposes you also want the second table so that you can quickly generate reports with weekly, monthly or yearly sums.
Is MySQL Timestamp a good option or should I use UNIX Timestamp?
Timestamp is good because there are lots of MySQL functions that work well with timestamp. You might also want to consider using datetime which is very similar to timestamp.
Related
Should I use field 'datetime' or 'timestamp'?