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.
Related
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.
I am stuck with a problem. In an app's db, I am having a schedule table which will store user provided schedules. E.g
Daily
Every Week
Twice a Week
Every 3rd (or any user chosen) day of week
Every Month
Twice a month
Every x day of month
Every x month of year
And so on. These schedules will then provide reference point to schedule different tasks or identify their repeat-ance.
I am not able to think of a proper database structure for it. The best I can get is to have a table with following columns:
Day
Week
Month
Year
type
Then store the specified schedule in the related column and provide the type.
e.g Every week can go like 1 in week column and 1 (designated value for repeating whole) or something like that.
The problem with this approach is that this table is gonna be used very frequently and the data retrieved will not be straightforward. It will need calculation to know the schedule type and hence will require complex db queries to get each type of schedule.
I am implementing it in Laravel app if that can provide any other methodology. It's a SAAS app with huge amount of data related to the schedule table.
Any help will be very much appreciated. Thanks
I suggest you are approaching the problem backwards.
Devise several rules. Code the rules in your app, not in SQL. When inserting an event, pre-fill a calendar through the next 12 months with all occurrences of the event. Every month, go through all events and extend the "pre-fill" through another month (13 months hence).
Now the SELECTs are simple and fast.
SELECT ... WHERE date = '...'
has all the events for that day (assuming it is within 12 months).
The complexity is on inserting. But presumably you insert less often than you select.
The table with the event definitions would be only as complex as needed for your app to figure out what to do. Perhaps
start_date DATE,
frequency ENUM('day', 'week', 'month', ...)
multiplier TINYINT, -- this lets you say "every second week"
offset TINYINT, -- to get "15th of every month"
Twice a week would be two entries.
Better yet, there are several packages (in Perl, shell, etc) that provide a very rich language for expressing event-date-patterns. Furthermore, you may be able to simply 'call' it to do all the work for you!
I have an AngularJS front-end app that sends requests to a Rails API back-end. When a user search for items, so far the query is limited to 20 elements and is always ordered by popularity (a field stored in database). After the results are retrieved from DB, there is a complex process that calculates the item prices iterating one by one (remember only 20 elements). After that, the results are served to the user. Note: As told, item prices cannot be calculated directly in the query because an item can have different prices according to dates and also discounts can be applied.
This is how it´s working so far.
Now, I would like to introduce in the search results page an innocent order by: Price functionality. So, the array of items should come ordered by price.
As, I can´t get the prices directly with just one query, I see two choices:
To keep it as it is right now, I mean, making the query ordered by popularity and order the results after the prices are calculated. But I see a problem, If I get 20 elements each time ordered by popularity, then I can calculate prices and order by price these 20 elements, so I assume I´m not ordering correctly by price. This case, I would need to query without limit, to get all items, calculate prices, order them by price and return to user. I think I would also to develop a home-made pagination functionality.
Develop some kind of stored procedure in the database to provide the results with the complex prices calculations. I don´t know if I can order them easily. I´m worried because I don´t know stored procedures in MySQL and not sure if it´s possible to do what I need.
But, from the performance point of view, I guess the second choice should be better, right? I´d appreciate comments or any other options?
UPDATE:
According to comments, I detail how to calculate prices functionality.
A user can rent an item for many days (a week i.e.). So, there is a check-in and check-out dates.
Also, prices changes according to seasons. This means days can have different prices in a selected week. So, in order to calculate the total price, you have to get the daily price matching each selected day in the week and add it to the total price.
Once, the base price is calculated, there can be discounts. Same as prices, discounts can be applied only for some days, so first, it must be checked if there is any discount for the selected week. If so, the discount is applied to base price to get the total final price.
Please, let me know if you need the code.
This should be done on the backend (MySQL).
Like you mentioned, if you want to sort by price on the front-end, you'll have to replicate the entire database into Angular. Which is probably a bad idea.
This is the approach I would take in MySQL:
Set up a table with item_id, date, and price (or perform the joins necessary to get this table).
Apply discounts for each date. This step yields an interim table with updated prices.
Build your final query. Your SELECT clause should SUM(price). You should GROUP BY item_id. And you should ORDER BY SUM(price) DESC.
Depending on the size of your database, this query may require a lot of fine-tuning in order to return results quickly. But it definitely can (and should) be done in the backend.
Good luck!
EDIT: With a really big set of items, running this query through MySQL may become too slow, regardless of how much time you spend tuning performance. If MySQL doesn't cut it, you may need to rely on an auxiliary database like Elasticsearch.
But before turning to Elasticsearch/Hadoop/etc, you should think carefully about how "complex" your pricing algorithm really is. In all likelihood you can optimize the MySQL query to the point where it performs just fine.
This is a classical search listing problem. If you want to perform sort based on price, obviously you need the required inputs. it is worth mentioning that stored procedure won't magically improve the performance. The best what you can do is run recurring CRON job every hour/day ( bonus tip : use upset and perform mass operation) which updates the price. Now perform join and do the query and order it with "price". Also make sure to put indexes on required fields. After grabbing the result apply discount and show the result. If query is complex the pagination won't work. You have to do all sorts of operation manually. If you are using will_paginate , it has some function which also support Array instead of active record. Hope this helps.
So you have the following factors then:
User Inputs Beginning Date, End Date and sees list of items.
The Beginning - End Date period (selected period) is consistent for all items in the query.
To sort by price you must, for each item in the table (not just those retrieved)
Get Item Price for each day of the selected period.
Get available discounts for each day of the selected period.
Calculate Total Price for selected period.
Because user input is involved you will not be able to definitively calculate this and store the final product. The best you could do is calculate the gross and net prices per day and cache that, then performing the final calculation based on user input (or sending that data to browser for calculation there)
You could also use a first order approximation and just go with the current gross value, and then tweak from there. That assumes that the relationship between item prices remains more or less consistent.
I'm trying to help a taxi company. The problem is that they have a credit card machine that takes payments, and has its own database entries, and there is a completely separate database that has a list of entries such as pick up time, and drop off time.
I need to match the database of trip entries to the credit card purchases, and the only way to do this is by matching which vehicle is running the transaction, and looking for a time CLOSE TO the DROP OFF time and see if it's a match. It's not ideal.
So, I am trying to compare two times in yy-mm-dd hh:mm:ss format. They need to be plus or minus 5 minutes of each other. How do I do this in MYSQL?
I thought SubTime and Addtime would work, and it seemed to, but then I got wierd results.
SELECT * FROM completedtrans WHERE DrivID = 128 AND TransTime BETWEEN SUBTIME('2013-06-20 16:53:06', '0 00:05:00') AND ADDTIME('2013-06-20 16:53:06', '0 00:05:00')
Here's an example of one of my searches. Can anyone tell me what's wrong with it? It's supposed to search 5 minutes before and after that particular given time. I can't simply write the time, because the query is automatically generated through php code.
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'?