I am wandering how should I design the database according to this requirements.
I have:
multiple users with calendars
multiple events for one date
one event can be assign to many dates
to each event is assign only one person (different than user this event belongs)
I would like to easily have access to all events for a particular date for specific user and also have access to get all dates for the specific event for the same user. Would be also perfect if I could get all events for which a given person is assigned.
I was thinking of creating Date table and Event table with userId and Dates columns and store all datesId for specific event but it won't be easy to get all user events for certain date and person.
Second idea was to create Date table and keep all information in one column for specific date in JSON format, something like:
user1:{event1, person1, event2, person2}, user2:{event3, person3, event4, person4}
But in this approach there will be difficult to get all dates for certain event and also for person.
Another idea was to create different calendar table for each user but this seems to be very inefficient and I guess problematic when adding new users.
Is there any good approach to achieve my goal?
Related
Could someone help to understand the efficient way of storing the timesheet data (Timesheet_Details)?
The timesheet data can be input in multiple ways
Start time and end time (9am to 5 pm)
Plain input of hours (8 hours)
Input like hours in multiples of 2 (2,4,8)
Based on unit like e.g. 1 = full day, 0.5 = half day.
What I have is a master Timesheet table which will store the start and end date for the job. But I am confused how to store the timesheet hours against each date.
Timesheet
id
client_uuid
user_uuid
job_uuid
start_date
end_date
Timesheet_Details
id
timesheet_uuid (FK)
date
?
?
?
You say that the timesheet data can be input in multiple ways (the four mentioned). Is it something you need to have in the interface of the application? Is it something you really need to duplicate in the database? What I mean is that even though the user experience that is asked is to be able to enter the time in multiple different ways, it does not need to be stored this way, the data can be transformed in a way that is consistent in the database, and then you would show the format according to the user preferences. You would use some algorithm to transform the data and store it correctly in the database.
For instance, you could add a table that contains all the possible ways of showing the time, listing the four that you mentioned here but with codes, let's name it "time_presentation". The interface would show a dropdown and the user would select a way to enter the time. The interface would change according to what they want (for example, two inputs to enter beginning and end, one input to enter only the hours, etc.). Then, the data would be sent to the backend and stored in the Timesheet_Details table but always with the same format that you will have calculated with the code, for example, a float column containing the total hours, and a column containing a foreign key to the table "time_presentation". Then, to show the item in the interface, you would be able to use both columns and reverse the process to show it according to what the user entered and how they entered it (if it's important the user sees it as entered).
If it's absolutly necessary to store the data directly with the 4 methods mentioned, then I would suggest using a varchar column with the value (but this would be a lot less easy to validate).
I am creating a booking management system in which it is allowed to create recurrent events.
Searching around, I understood that creating "repeating patters" would be an optimal idea for the DB design, as explained here: Calendar Recurring/Repeating Events - Best Storage Method
My issue comes from the fact that I would need to add some data for each single event, such as if payments have been made for each single event, confirmation, notes, etc.
This would end in creating a different table with a single row for each event created. In other words, physically adding a row for each event instead of using "recurrent patterns".
I can't see a solution for avoiding 1 line in the DB for 1 event. Any suggestion? In my system, each user would not have many events, let's say a maximum of 50 events per week.
Let's assume you have a table already to store recurrent events, such as
table recurrent_event
id bigint
start date
interval int -- as simple or complex as needed
Now your application will need some logic anyway to calculate which single events will come from this, e.g. to display a list of single events. I would not store a list of all these singles events in the database, as, initially, this list wouldn't add any useful information. Also, the list would have to end somewhere, so it might fail to encompass all single events coming from the recurrent event. The only need to insert a record for a single event arises when some additional information for the event gets actually entered. Just for these single events, I'd create a
table single_event_additional_info
id bigint
recurrent_event_id bigint
single_event_date date
additional-information ... whatever datatype fitting
that points back to the recurring event. So, when treating a recurring event, selecting from this table all single events referring to it will yield all information relevant for the recurring event. The rest of single events will still be determined by calculation.
Consider this scenario,
I have a booking table that shows dates and different events that may be booked, and I need to write a query that will display all bookings made within two specific dates given.
Is there any way that the two dates can be user-inputted during the runtime of the query?
PostPosted: 09 May 2014 22:26
Post subject: Determine table based on prompt
Hello,
I have three fact tables. First table holds current data, FACT_CUSTOMER_CURRENT. Other two tables hold historical snapshots. For example, one of these table holds last 60 days' records- FACT_CUSTOMER_DAILY. The other table holds data for the last day of the months.-FACT_CUSTOMER_MONTHLY
I want to add a date prompt. If the user selects yesterday as a prompt value, report should bring value from first table which holds current data (FACT_CUSTOMER_CURRENT). If user enters 28.02.2014, the report should retrieve data from FACT_CUSTOMER_MONTHLY. I tried to use context and aggregate awareness, but I could not be successful.
Can you help me?
Kind regards
There's no direct, easy way to do what you want.
Aggregate Awareness is useful for selecting a table based on the selection of objects in a query, but it does not support dynamic selection of tables based on values in a prompt.
If yesterday's data will only exist in fact_customer_current, then you can use this method: In your report, create a UNION query. One query includes objects from fact_customer_current, and the other from fact_customer_monthly. They both have an identical prompt on the appropriate date field. When a user enters yesterday's date, the first UNION query will return data but the second one won't. Likewise for date before yesterday, the first UNION will return no data but the second one will. This solution requires that the tables are correctly indexed such that a query on a date that isn't in the table will return quickly.
I'd like to keep track of the operations of an application that uses a mysql database mostly read-only. I know that there are a lot better ways to keep track of operational metrics, but as a quick and dirty start would it be horrible to have table with date and hour_of_the_day columns and then a count column to keep track of the occurrences of some event during that hour?
There would be a lot of contention on only a few rows, right? Is this preferable to created in an entire new row per event?
If you're going to go this route, which I don't think is a bad idea, you might want to create a new row per event. You can have columns such as event type (an ID), datetime of event, etc. You could then count the events by doing a count() query on a certain event type.
Then you can link it to an EventType table to where you specify what each event type is, such as name of event, description, etc