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.
Related
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.
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 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.
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.
I'm writing an application that I will use to keep up with my monthly budget. This will be a C# .NET 4.0 Winforms application.
Essentially my budget will be a matrix of data if you look at it visually. The columns are the "dates" at which that budget item will be spent. For example, I have 1 column for every Friday in the month. The Y axis is the name of the budget item (Car payment, house payment, eating out, etc). There are also categories, which are used to group the budget item names that are similar. For example, a category called "Housing" would have budget items called Mortgage, Rent, Electricity, Home Insurance, etc.
I need a good way to store this data from a code design perspective. Basically I've thought of two approaches:
One, I can have a "BudgetItem" class that has a "Category", "Value", and "Date". I would have a linear list of these items and each time I wanted to find a value by either date or category, I iterate this list in some form or fashion to find the value. I could probably use LINQ for this.
Second, I could use a 2D array which is indexed first by column (date) and second by row. I'd have to maintain categories and budget item names in a separate list and join the data together when I do my lookups somehow.
What is the best way to store this data in code? I'm leaning more towards the first solution but I wanted to see what you guys think. Later on when I implement my data persistence, I want to be able to persist this data to SQL server OR to an XML file (one file per monthly budget).
While your first attempt looks nicer, obviusly the second could be faster (depends on how you implement it). However when we are talking about desktop applications which are not performance critical, your first idea is definitely better, expecially because will help you a lot talking about maintaining your code. Also remember that the entity framework could be really nice in this situation
Finally if you know how to works with XML, I think is really better for this type of project. A database is required only when you have a fair amount of tables, as you explained you will only have 2 tables (budgetitem and category), I don't think you need a database for such a simple thing