Develop Reference

SQL Server / EF : keeping track of person's expected attendances

For a school project I'm trying to keep track of students (subclass of person), their attendance (eg. wednesday 27-02-2019), and the days they are expected (eg. every monday and wednesday). There are only 5 possible combinations of expected days.
So far I've created a table Person with a discriminator for Student, and a table Attendance with a bridge table between Person and Attendance.
I have no idea how to keep track of the days they are expected to show up.
The administrator should be able to get a list of students per day, students per expected day combination (eg. Monday & Wednesday is a possible combination) and attendance per student.
I'm struggling to figure out how to store the expected days, my first guess was creating a list with 2 elements, but since this isn't allowed in SQL, I have no idea what other options I have since creating another table for days feels kind of wrong because I already have a table for attendance.

Is there a canonical way for storing data to assist in calculating when a recurring operation should next take place?

I am writing a utility to configure when certain reports are going to be automatically generated.
The next piece will be some background task (probably a Windows Service) that will poll the database to know when to execute these recurring operations. I came up with this initial table design:
ReportScheduler
---------------
AutoID int
MemberID VarChar(6)
ReportID int
RunWhen DateTime
...but soon realized that "RunWhen" isn't going to cut the catsup, because there are going to be multiple times a given report needs to be run for a given Member (once it runs, the value is no longer valid/useful).
Before showing the next candidate table design, though, a word about when these reports can be done (generated and emailed): the configurer can set them up to be run on a particular day of each month (the 1st, the 10th, the 17th, whatever) OR according to a pattern, i.e. they can be set to something like "the first Tuesday of each month" or "the last Friday of each month" or "the first Monday of each week" (IOW, every Monday). So I came up with this:
ReportScheduler
---------------
AutoID int
MemberID VarChar(6)
ReportID int
DayOfMonth int
PatternOrdinal VarChar(6) // First, Second, Third, Fourth, or Last
PatternDOW VarChar(9) // Monday, ... Sunday
PatternInterval VarChar(5) // Week, Month
...but then realized that that doesn't make too much sense, either, because code would have to run to calculate whether any date that equates to the DayOfMonth or Pattern combination of fields has been reached or surpassed every time the db is polled. And then what would prevent that from triggering forever after that, too?
SO, I think I need to combine these ideas, but instead of RunWhen, call the DateTime field NextExecution, and update it each time the report is generated for a given Member:
ReportScheduler
---------------
AutoID int
MemberID VarChar(6)
ReportID int
NextExecution DateTime
DayOfMonth int
PatternOrdinal VarChar(6) // First, Second, Third, Fourth, or Last
PatternDOW VarChar(9) // Monday, ... Sunday
PatternInterval VarChar(5) // Week, Month
When the NextExecution time is reached or surpassed, the Service generates/emails the report. It then calculates when the next execution should take place (based on the DayOfMonth or Pattern* fields) and updates the NextExecution field with that value.
This seems logical to me, but I'm sure this is a challenge that has been met before, and wonder if there is a standard way of accomplishing this that may be cleaner than what I've proposed.

Assuming that you're keeping a log of when these reports have been run, you could use that with your second method to prevent a report from running multiple times. You might want to incorporate some sort of rule that you will only try to run reports that have passed their due date within "X" days also.
Another potential design would be to keep a table similar to your first method, but fill it in when a person creates a new schedule out through the next 10 years (or some other sufficiently large time span). Keep a table that lists out the schedules that have been created by users and link the scheduled dates back to those schedules so that you can delete them if the user cancels a schedule. You'll need to decide what you want to do about schedules that overlap (both schedules happen to land on the same day this month and call for the same report to be run for example). Do you run the report once or twice? How you handle that determines how you might have to code around maintaining the calendar when a user creates/deletes schedules.

Schedule Table Design

I am working on doctor scheduler page requirement. The below is the screen for showing a usual weekdays schedule for a doctor.
The doctor may visit only few days on a week and only between a period of time
A doctor may be on leave some day. They add that entry
I need to design the database table to handle above scheduling.
I have no idea how a database table can be designed for 7 days with hours and doctors mapped.
The most important thing is for a given week i should be able to check the doctor availability.
I created a DoctorLeave table below to handle only doctor leave days
DoctorId, LeaveDate, Comment
But, How do i design scheduler table? Any idea/suggestions pls

I’d go with a structure that looks like this
-Doctor_ID
-Patient_ID
-Activity_Start
-Activity_End
-Activity_Type_ID
For activity type I’d create a lookup table that could look like this
Activity_Type_ID Activity_Description
1. Working with patients
2. Absent

Your table for scheduling should be simple. All you need are doctor_id, patient_id, begin_time, end_time (both fields containing both date and time). Then your query or UI code figure out which day of the week those lie on and how to display them on a schedule table, etc.
You should create a separate table for doctor unavailability. doctor_id, leave_begins, leave_ends (both as dates and times if necessary). Once again, use your queries or UI code to figure out conflicts during appointment scheduling.

How to represent aggregate entities using Code-First?

I have recently started developing using ASP.NET and am struggling to grasp Code-First. I am working on a project for an internship and have very little database knowledge except for one class I've taken. I am in no way asking for a complete solution or being lazy.
I've been trying for a couple days to create a solid ER diagram and I'm fairly certain the one below will represent all of the information I need to store. Please let me know if you see any ways this can be improved.
What I'm trying to do:
For this project an administrator will create rooms with attributes listed below. The admin will then assign time-slots that represent between what hours the room will be available and what days of the week it will be available.
The users will fill out their basic information and fill out a form representing what times they are available.
After all the users have registered the admin will run a scheduling algorithm to come up with the closest to a most efficient schedule that it can (because it's NP hard).
The assigned relation represents user time slots that are related to room time slots in order to produce a table of what users are assigned to what rooms at what times.
I'm using Visual Studio 2012.
Questions
How would I represent these aggregate entities using Code-First? Not necessarily asking for the code for this exact diagram but maybe quick example to help me wrap my head around Code-First.
Do my mappings look correct for these relations?
Any help or point in the right direction is greatly appreciated!! Thank you!
Below is an ER diagram that represents the following:
Room (id, number, building, capacity)
TimeSlot (id, startHour, endHour, dayOfWeek)
User (id, firstName, lastName, email)
Available (userId, timeID)
Reserved (roomID, timeID)
Assigned (reservedID, availableID)

Firstly in the ER diagram I would have expected a link directly from Room to TimeSlot (top-right) and User to Timeslot (bottom right), but knowing the likely queries that will be run I would suggest the ERD should be as follows.
Room linked to an entity called RoomAvailability. RoomAvailability contains all the free time slots for rooms, so this will initially be populated with one record per room per day (RoomId, Date, StartTime, EndTime) going to as many days into the future as you think necessary.
Similarly I would have an entity UserAvailability (UserId, Date, StartTime, EndTime) linked to User.
Entity RoomReservation (RoomId, UserId, Date, StartTime, EndTime) linked to both Room and User which contains all room reservations (assumes only 1 user can book a room).
When a room is reserved a RoomReservation records is added and a single RoomAvailability record may be split into 2 separate ones (e.g. room is free for whole day then someone books a slot during the day leaving 2 free periods at the start and end of the day).
When a reservation is cancelled the RoomReservation record is deleted and 2 RoomAvailability records may be merged back into 1 (the reverse of the above).
I believe that splitting and merging of available slots is how similar systems work.

Reocurring until infinity

Let's say I wanted to display a Reminder (dynamically created by user) in my ASP.NET MVC View
Every WEEK/MONTH/.... until "infinity".
This reminder has to be seperate database record (or in my case EF Entity Instance object) for each reocurrence, because i'm storing specific data in my database for each occurrence.
How would you guys go about "inserting" these reminder clones into the database?
I Can't insert infinite reminders, .. And choosing an arbitrary date say "2000 years" from now seems wrong, and also inserts a lot of records into the database.
Kind of clueless here...
Thanks in advance for any (alternative) solution/ advice.
*It is key tough that i can store data for each occurence!*

Inserting reminders into the database, IMHO, is a bad way of implementing it. It is just lazy.
My approach would be to store the conditions and then test the conditions on a regular basis. Perhaps just keeping a timestamp of last reminder check and if it is more than 8 hours, re-calculate - something around these lines.
UPDATE
In order to know which reminder has been seen by the user or not, for every type you just keep a timestamp of when it was read. If the difference is more than the item interval, then it must be shown. If timestamp is less than the the time reminder must be shown, then it must be shown.

Is there the remotest possibility that your code will be used in 10 years time?
If not try 10 years.