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.
Related
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.
I'm having issues within a site that I recently took over. It is a school site that uses a table where students can reserve seats for classes. The issue I'm running into is that the classes disappear the day of and students think the class is canceled. The customer wants the class to be visible until the day after the class is over. I'm not really sure how tables like this work in ASP.Net. Any help would be great.
PCC Public Safety
Not much to go on, but first thing that comes to mind.
now() <= '1/1/2014'
Actually means Midnight on the Jan 1st 2014. If they have all day to signup, try somthng like:
now() <= '1/1/2014 23:59:59'
That will give them until midnight on the day.
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.
We have a billing system where we process individual charges as well as recurring charges (subscriptions).
There are two SQL tables:
StandardCharges
RecurringCharges
StandardCharges table holds individual items purchased by customers during the month.
RecurringCharges table holds recurring items with a charge by date. When the time comes our system automatically creates a recur request which adds a row to the StandardCharges table and increases the charge by date to next month in RecurringCharges table.
At the end of each month we get the total values for each customer from StandardCharges table and create an invoice.
Is there a kind of design pattern or another way of doing this? Is this the right database design? Ideally I would like to hold all charges in one Charges table and manage recurring charges from there as well?
Thanks
I suspect that your design is indeed correct.
When thinking about the data in real world terms it makes no sense to have "possible" transactions (I.E., transactions which have not yet happened and may not materialize, perhaps because the customer had overrun their credit limit) mixed in with committed and actual transactions.
Merging the data into a single table can also make reporting difficult as you have to apply special filtering criteria and store extra meta data - like TransactionCompleted and TransactionIsFutureCharge.
If I was to make a suggestion it would be renaming the StandardCharges to something closer to the data it holds like CompletedTransactions and the RecurringTransactions something like PendingTransactions.
The current design seems reasonable to me. But if you want to merge the two tables, you could simply add a BIT column called IsRecurring or IsFuture or IsScheduled or whatever you want to use to designate the charges that would have otherwise gone in RecurringCharges. Then when your due date is hit for a recurring charge, you just insert into the same table instead of a different table. As for the invoice, you'd just add a condition to the query to filter out the charges that have the BIT column set.
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.