For this application, staff need to be able setup when they start & end each day of the week. They can optionally have that start/end repeat every 1, 2, or 4 weeks. For example, I start work at 9am and finish at 2pm every Monday. With simple recurrences like that, I'm thinking of having 3, maybe 2 models (for denormalization):
Event
- start: datetime
- end: datetime
- type: int (appointment, time off, cancelled, etc)
- date: date (useful?)
- staff_id: int
- customer_id: int
(more, redacted)
DayTemplate
- active_start: datetime
- active_end: datetime
- staff_id: int
Day
- weekday: int
- start: datetime
- end: datetime
- recurrence: int (0: none, 1: once/mo, 2: other week, 4: every week)
- day_template_id: int
The idea is that the parameters are now set, so customers can go in and book a staff when they're available (in specific chunks, say 9am, 10:15am, 11:30 -- to allow for breaks to be setup). For any day on the schedule, you can easily query for that staff members active DayTemplate. Staff can then further tweak the schedule by booking events as "time off" to give them fine-tune control. Additionally, I was thinking of denormalizing Day into DayTemplate - I know it would look ugly, but the schema would never change, and the performance benefits would make it worth it? Is this enough flexibility?
Appreciate the feedback. I'll be building this in rails.
For this application, staff need to be able setup when they start & end each day of the week. They can optionally have that start/end repeat every 1, 2, or 4 weeks. For example, I start work at 9am and finish at 2pm every Monday. With simple recurrences like that, I'm thinking of having 3, maybe 2 models (for denormalization):
Dont denormalize yet. Focus on getting the business rules down, then map those to business objects in rails. Let the schema design be driven by specific app requirements.
Additionally, I was thinking of denormalizing Day into DayTemplate - I know it would look ugly, but the schema would never change, and the performance benefits would make it worth it?
For sure you should not be worrying about optimizing for performance at this point. Instead optimize for clarity and simplicity. Chances are the aspects of your app that will need performance optimization will be totally different than what you would have guessed upfront.
Is this enough flexibility?
Maybe too much. I'd recommend building the simplest possible thing you can that meets the minimum acceptance criteria. Don't try and engineer in flexibility, it's too hard to guess upfront what kind of flexibility will be required. Over time the cost of maintaining all of these "maybe-we-will-need-this-someday" features will get in the way of building stuff your real users actually want. It's counter-intuitive but keeping things as simple as possible now is the best way end up with a really feature-rich system down the line. Optimize for speed-to-deliver, get it in the hands of real users and start collecting feedback.
Also, the thing about building any kind of scheduling system is that the complexity gets out of hand really quickly. If you're doing this as an exercise it may be worth it to try and code yourself, but if this is something you really need to get done seriously consider using one of the many ruby gems designed to help with modeling/scheduling recurring events. Personally I have used ice cube but there are many choices at the ruby toolbox
Related
I’m trying to find the best practice for how to store and then query a event like this. User has purchased 3 items on separate dates.
Over that period there were two events that were held (events added in well after the user purchased the items as a retrospect, so at the time of purchase, event was not known). I’m trying to see how many items were purchased during each event by that user. How should I do that?
One solution but it sounds weird to me: When inserting a event, scan and add a relationship to all vertices that match
Manage date-time types isn't exactly an easy task on Neo4j, even in 3.2 version.
You have two options:
Hard way: convert all date to unix "timestamp" format ('s' or 'ms' from 1970), in order to calc date ranges.
Easy, convenient way: use "APOC" (here), a set of procedures and functions available as plugin for Neo4j; installation can be a bit tricky but it's worth it, indeed. It has a good number of 'date-time' functions.
The question
How do you handle a change in grain (from weekly measurement to daily measurement) for a snapshot fact table.
Background info
For a star-schema design I want to incorporate the results of a survey as a fact (e.g. in week 2 of 2015 80% of the respondents have responded 'yes', in week 3 76% etc.)
This survey is conducted each week, and I only have access to the result of the survey (% of people saying yes this week) and not to the individual responses.
Based on (my interpretation of) Christopher Adamson's "Star Schema: The complete reference" I believe I should use a snapshot fact table for these kind of measurements.
The date dimension for this fact should be on the week-level, and be a conformed rollup of a more fine-grained date dimension for other facts in other stars that take place on a daily basis.
Here comes trouble
Now someone decides they want to conduct these surveys daily instead of weekly. What is the best way to handle this? Some of the options I'm currently considering:
change the week dimension to a daily one, and fake the old facts as if they happened on the last day of the week.
change the week dimension to a daily one, and add 7 facts for each weekly one.
create a new star, with the daily fact and dimension and treat the old one as an aggregate.
I'd appreciate any input. Please tell me if my logic is off, or my question is not clear :)
I'm not convinced that this is a snapshot. Each survey response represents a "transaction".
With an appropriate date dimension you can calculate the Yes/No percentages, rolled up by week.
Further, this would enable you to show results like "Surveys issued on a Sunday night get more responses", or "People who respond on Friday are more likely to answer 'Yes'". (contrived examples)
Following clarification, this does look like a periodic snapshot. The example of a bank account balance is often used to describe a similar scenario.
A key feature of a periodic snapshot is that every combination of every dimension should be present. If your grain is monthly, then every month you record the fact, even if it has not changed from the previous month.
I think that is the key to your problem. Knowing that your grain may change from weekly to daily, make your grain daily. It does mean you'll be repeating the weekly value on every day of the week, but that is a true representation of your knowledge of the fact; on Wednesday you only knew that its value was the same as Monday.
If you design your ETL right, you won't need to make any changes when the daily updates begin.
Your second option is the one I'd choose in your place.
I am to store quite large amount of boolean values in database used by Rails application - it needs to store 60 boolean values in single record per day. What is best way to do this in Rails?
Queries that I will need to program or execute:
* CRUD
* summing up how many true values are for each day
* possibly (but not nessesarily) other reports like how often true is recorded in each of field
UPDATE: This is to store events that may or may not occur in 5 minute intervals between 9am and 1pm. If it occurs, then I need to set it to true, if not then false. Measurements are done manually and users will be reporting these information using checkboxes on the website. There might be small updates, but most of the time it's just one time entry and then queries as listed above.
UPDATE 2: 60 values per day is per one user, there will be between 1000-2000 users. If there isn't some library that helps with that, I will go for simplest approach and deal with it later if I will get issues with performance. Every day user reports events by checking desired checkboxes on the website, so there is normally a single data entry moment per day (or few if not done on daily basis).
This is dependent on a lot of different things. Do you need callbacks to run? Do you need AR objects instantiated? What is the frequency of these updates? Is it done frequently but not many at a time or rarely but a bunch at once? Could you represent these booleans as a mask instead? We definitely need more context.
Why do these need to be in a single record? Can't you use a 'days' table to tie them all together, then use a day_id column in your 'events' table?
Specify in the Day model that it 'has_many :events' and specify in the Event model file that it 'belongs_to :day'. Then you can find all the events for a day with just the id for the day.
For the third day record, you'd do this:
this_day = Day.find 3
Then you can you use 'this_day.events' to get all the events for that day.
You'll need to decide what you wish to use to identify each day so you query for a day's events using something that you understand. The id column I used above to find it probably won't work.
You could use the timestamp first moment of each day to do that, for example. Or you could rely upon the 'created_at' column of the table to be between the start and end of a day
And you'll want to be sure to thing about what time zone you are using and how this will be stored in the database.
And if your data will be stored close to midnight, daylight savings time could also be an issue. I find it best to use GMT to avoid that issue.
Good luck.
I'm working on a Rails application that allows users to define Tasks, which require a due_date. The due_date may or may not include a time.
The way we're handling this right now feels like a hack. due_dates default to 12:00 AM, and in that case we don't display a time. The DateTime object doesn't allow for empty Time values as far as I know.
Should I split this information up into two columns in the database? How do you guys handle this?
Since your data structure needs to accommodate dates with and without a time, you have two choices:
Use a Ruby DateTime object with a flag value for the time to indicate that the date does not have a time. The usual flag value for this is 0 which then means the midnight time can't be shown. (Midnight is 0 seconds after the day has started.)
For example, parsing "Jan 1, 2010" into a DateTime will give you Jan 1, 2010 00:00.
Otherwise you'll need to invent your own data structure. Easiest would probably a Class with a DateTime and a "show_time" boolean flag. -- by using a DateTime to hold the time, you'll be able to use the DateTime output methods, and do arithmetic with them if needed.
Creating a new data structure is not such a big deal in Ruby, but if you can live without tasks due exactly at midnight, I'd recommend method 1. Note that you'd probably want to print them without a time since that's what the task definer requested. Or you could include "(any time)" in the output.
PS
Watch out for timezones! Many ways to handle, but you should be sure to choose one deliberately.
Splitting the attributes may be unnecessarily complex. Why not adopt a convention that if no time is specified then default it to midnight or noon on the date in question? Unless you need to be able to distinguish between the two cases, i.e. this is midnight because it was explicitly specified or this is midnight because no time was specified. If the latter then splitting them might be advisable or just add a boolean to disambiguate the cases.
If you thought you had further use for a separated date and time and would expend lots of energy splitting a single field for other reasons then that might also argue for splitting.
What I want to do is very simple but I'm trying to find the best or most elegant way to do this. The Rails application I'm building now will have a schedule of daily classes. For each class the fields relevant to this question are:
Day of the week
Starting time
Ending time
A single entry could be something such as:
day of week: Wednesday
starting time: 10:00 am
ending time: Noon
Also I must mention that it's a bi-lingual Rails 2.2 app and I'm using the native i18n Rails feature. I actually have several questions.
Regarding the day of the week, should I create an extra table with list of days, or is there a built-in way to create that list on the fly? Keep in mind these days of the week will have to be rendered in English or Spanish in the schedule view depending on the locale variable.
While querying the schedule I will need to group and order the results by weekday, from Monday to Sunday, and of course order the classes within each day by starting time.
Regarding the starting time and ending time of each class would you use datetime fields or integer fields? If the latter how would you implement this exactly?
Looking forward to read the different suggestions you guys will come up with.
I would just store the day of the week as an integer. 0 => Monday ... 6 => Sunday (or any way you want. ie. 0 => Sunday). Then store the start time and end time as Time.
That would make grouping really easy. All you would have to do is sort by the day of the week and the start time.
You can display this in multiple ways, but here is what I would do.
Have functions like: #sunday_classes = DailyClass.find_sunday_classes that returns all the classes for Sunday sorted by start time. Then repeat for each day.
def find_sunday_classes
find_by_day_of_week(1, :order -> 'start_time')
end
Note: find_by probably should have id at the end but that's just preference in how you want to name the column.
If you want the full week then call all seven from the controller and loop trough them in the view. You could even create detail pages for each day.
Translation is the only tricky part. You can create a helper function that takes an integer and returns the text for the appropriate day of the week based on local.
That's very basic. Nothing complicated.
If your data is a Time then I would store that as a Time - otherwise you will always have to convert it out of the database when you do date and time related operations on it. The day is redundant data, as it will be part of the time object.
This should mean that you don't need to store a list of days.
If t is a time then
t.strftime('%A')
will always give you the day as a string in English. This could then be translated by i18n as required.
So you only need to store starting time and ending time, or starting time and duration. Both should be equivalent. I would be tempted to store ending time myself, in case you need to do data manipulations on ending times, which therefore won't have to be calculated.
I think most of the rest of what you describe should also fall out of storing time data as instances of Time.
Ordering by week day and time will just be a matter of ordering by your time column. i.e.
daily_class.find(:all, :conditions => ['whatever'], :order => :starting_time)
Grouping by day is a little more tricky. However this is an excellent post on how to group by week. Grouping by day will be analogous.
If you are dealing with non-trivial volumes of data, it may be better to do it in the database, with a find_by_sql and that may depend on your database's time and date functionality, but again storing the data as a Time will also help you here. For example in Postgresql (which I use), getting the week of a class is
date_trunc('week', starting_time)
which you can use in a Group By clause, or as a value to use in some loop logic in rails.
Re days-of-week, if you need to have e.g. classes that meet 09:00-10:00 on MWF, then you could either use a separate table for days a class meets (keyed by both class ID and DOW) or be evil (i.e. non-normalized) and keep the equivalent of an array of DOW in each class. The classic argument is this:
The separate table can be indexed in a way to support either class-oriented or DOW-oriented selects, but takes a bit more glue to put the entire picture together for a class.
The array-of-DOW is simpler to visualize for beginning programmers and slightly simpler to code about, but means that reasoning about DOW requires looking at all classes.
If this is only for your personal class schedule, do what gets you the value you're looking for, and live with the consequences; if you're trying to build a real system for multiple users, I'd go with a separate table. All those normalization rules are there for a reason.
As far as (human-readable) DOW names, that's a presentation-layer issue, and shouldn't be in the core concept of DOW. (Suppose you decided to move to Montreal, and needed French? That should be another "face" and not a change to the core implementation.)
As for starting/ending times, again the issue is your requirements. If all classes begin and end at hour (x:00) boundaries, you could certainly use 0..23 as the hours of the day. But then your life would be miserable as soon as you had to accommodate that 45-minute seminar. As the old commercial said, "Pay me now or pay me later."
One approach would be to define your own ClassTime concept and partition all reasoning about times to that class. It could start with a simplistic representation (integral hours 0..23, or integral minutes after midnight 0..1439) and then "grow" as needed.