Problem
I need to make design database(ERD) for displaying schedule for every instructor
include
day of course(Saturday or Monday,etc)
And which time it will give course(period FROM 12 PM TO 03 PM ) .
And what course it will give(c# or SQL) .
Example
Instructor martin give course c# in Monday and Saturday for period 12 pm - 03 pm
And SQL in Sunday and Wednesday for period 12 pm - 03 pm .
Details
So that i designed the following tables :
Instructors table (InstractorID,InstractorName)
Courses table (CourseID,CourseName)
Instructors_courses table (instcourseID,InstractorID,CourseID)
And relation between instructors table and Courses table many to many so that
I do another table is Instructors_Courses table .
My questions are
1- How to represent days and time for every course added
Can i add table for time and table for days and make relation with
Instructors_courses table by adding day id and time id (one to many)
OR do it programming from user interface .
2- course start date and course end date these two fields how to represent in
table Instructors_courses table .
i can added but it will repeated with every course are this correct or what .
You can have autoincrement or some coding pattern. For example MON8A10A means Monday 8-10AM. This is only going to work if you have only one classroom. If rooms also have codes you can add that too (MON8A10AR1). That way you can manage the courses, instructors and their time slots. You may add time start time, end time, day and classroom as columns as well.
Adding course start date and end date in course_instructor table is not wise since it is going to duplicate data. But your approach varies according to amount of data you have and the responsiveness of the system. If you have a lot of data and need to save storage better to have a separate table for that. But you need to create a relationship with that. Having multiple relationships can slow the retrieving results. But that is for very long relationships. If you only have 2 or 3 it will not a matter.
Related
Right now I am developing Hotel reservation system.
so I need to store prices on certain date/date range for future days, so the price varies on different days/dates. so I need to store those price & date details in to db. i thought of 2 structures .
1st model :
room_prices :
room_id :
from_date :
to_date :
price:
is_available:
2nd design:
room_prices :
room_id :
date:
price:
is_available
so i found the 2nd method is easy. but data stored grows exponentially
as my hotel list grows.
say suppose if i want to store next(future) 2 months price data for one hotel i need to create 60 records for every hotel.
in case of 1st design, i don't require that many records.
ex:
```
price values for X hotel :
1-Dec-15 - 10-Dec-15 -- $200,
1st design requires : only 1 row
2nd design requires : 10 rows
```
i am using mysql,
does it have any performance degradation while searching
room_prices table.
would someone suggest me any better design ?
I have actually worked on designing and implementing a Hotel Reservation system and can offer the following advice based on my experience.
I would recommend your second design option, storing one record for each individual Date / Hotel combination. The reason being that although there will be periods where a Hotel's Rate is the same across multiple days it is more likely that, depending on availability, it will change over time and become different (hotels tend to increase the room rate as the availability drops).
Also there are other important pieces of information that will need to be stored that are specific to a given day:
You will need to manage the hotel availability, i.e. on Date x there
are y rooms available. This will almost certain vary by day.
Some hotels have blackout periods where the hotel is unavailable for short periods of time (typically specific days).
Lead Time - some Hotels only allow rooms to be booked a certain
number of days in advance, this can differ between Week days and
Weekends.
Minimum nights, again data stored by individual date that says if you arrive on this day you must stay x number of nights (say over a weekend)
Also consider a person booking a week long stay, the database query to return the rates and availability for each day of that stay is a lot more concise if you have a pricing record for each Date. You can simply do a query where the Room Rate Date is BETWEEN the Arrival and Departure Date to return a dataset with one record per date of the stay.
I realise with this approach you will store more records but with well indexed tables the performance will be fine and the management of the data will be much simpler. Judging by your comment you are only talking in the region of 18000 records which is a pretty small volume (the system I worked on has several million and works fine).
To illustrate the extra data management if you DON'T store one record per day, imagine that a Hotel has a rate of 100 USD and 20 rooms available for the whole of December:
You will start with one record:
1-Dec to 31st Dec Rate 100 Availability 20
Then you sell one room on the 10th Dec.
Your business logic now has to create three records from the one above:
1-Dec to 9th Dec Rate 100 Availability 20
10-Dec to 10th Dec Rate 100 Availability 19
11-Dec to 31st Dec Rate 100 Availability 20
Then the rate changes on the 3rd and 25th Dec to 110
Your business logic now has to split the data again:
1-Dec to 2-Dec Rate 100 Availability 20
3-Dec to 3-Dec Rate 110 Availability 20
4-Dec to 9-Dec Rate 100 Availability 20
10-Dec to 10-Dec Rate 100 Availability 19
11-Dec to 24-Dec Rate 100 Availability 20
25-Dec to 25-Dec Rate 110 Availability 20
26-Dec to 31-Dec Rate 100 Availability 20
That is more business logic and more overhead than storing one record per date.
I can guarantee you that by the time you have finished your system will end up with one row per date anyway so you might as well design it that way from the beginning and get the benefits of easier data management and quicker database queries.
I think that the first solution is better and as you already noticed it reduce the number of storage you need to store prices. Another possible approach could be : having a single date and assuming that the date specified is valid up until a new date is found, so basically the same structure you designed in the second approach but implementing an internal logic in which you override a date if you find a new date for a specified period.
Let's say that you have ROOM 1 with price $200 from 1st December and with price $250 from 12 December, then you will have only two rows :
1-Dec-15 -- $200
12-Dec-15 -- $250
And you will assume in your logic that a price is valid from the specified date up until a new price is found.
I want to create a SQL table in my database that can hold a school timetable but every way i tried to proceed with it it was no optimal and over the course of 1-2 changes to the timetable the database table got a bit too big.
It goes a bit like this:
Mo Tu Wed Thu Fri
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
This is the basic layout of the timetable and in the table the first 2 columns are timetableid and classid. My first approach was to have columns for each day with the classes in one column but that was a bit buggy, my next approach was to get the columns like this mo_7, mo_8, mo_9 etc. until i reach fri_16 but that took up too much space.
So my question is, what is the most optimal way to save a timetable in a database, in what table layout.
Thank you in advance.
Your problem isn't your database, it's because you're trying to use it like a spreadsheet.
You need to backtrack a little - store a table of classes, along with the various attributes. If each class has only one session, then add 'time' as an attribute. If there's multiple sessions, your probably then need to separate out the schedule into a seperate table.
E.g.:
Table 'classes':
ClassID.
description
teacher
other stuff.
Table 'sessions':
session ID
ClassID
start_time
end_time
day
location
And then you'd use a select to query e.g.
SELECT classID, start_time, day, location
FROM sessions
WHERE day like "Monday"
ORDER BY start_time
Which'd give you your list for Monday. To extend it, you might add a join with the 'classes' table.
SELECT classes.description, classes.teacher, sessions.start_time, sessions.day, sessions.location
FROM sessions, classes
JOIN ON classes.ClassID = sessions.ClassID
WHERE day LIKE 'Monday'
ORDER BY sessions.start_time
Something like that anyway (apologies if the syntax is a bit off, I'll check/amend if I can).
But the point is - let the database store the actual data and use the queries to transform it into a layout that you like. That way you don't need to rewrite your database each time you want to change something minor.
I am trying to create a timetable for classes in MySQL. The columns are the days of the week and the rows are the time intervals ( i.e. 7:00 - 8:00 ). I am also trying to have 30-minute time intervals and when a particular subject is 2 hours, it will span 4 rows. Each cell contains the name of the course and room. This is part of a small program I am trying to develop. So far, I know what data to insert but I'm stuck on creating the right database schema. Really need the logic on how to get this started (i.e. what data types should I use ). Thanks!
How does this sound:
CREATE TABLE TimeTable (
ID int(8) NOT NULL AUTO_INCREMENT,
Subject varchar(32) NOT NULL,
Room varchar(8) NOT NULL,
StartTime datetime NOT NULL,
EndTime datetime NOT NULL,
Day enum('Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday') NOT NULL,
PRIMARY KEY (ID)
);
You only store the data about the subjects.
The other stuff you mentioned is really down to whatever language you're using to output the data. You can't really put intervals in the middle of a database. As Damien_The_Unbeliever said, databases aren't exactly spreadsheets.
Hope this make sense.
You can set one column for day (you can value days from 1 to 7), one column for starting time and one column for finish time. This way your queries will become more simple.
Example:
Day | Start | Finish
-----------------------------
1 8:30 12:00
1 13:00 15:00
This will also come in handy when you don't want to stuck with 30 minutes.
The columns are the days of the week and the rows are the time intervals ( i.e. 7:00 - 8:00 )
That's a bad start. Your columns should be properties of a single lesson and your rows should be all the different lessons throughout the week.
Your columns could be Day of Week, Lesson of Day, Duration, Subject, Room, Teacher, et cetera. In this example, your primary key would be (Day of Week, Lesson of Day).
This way, if you want the schedule for a particular day you just select everything with Day of Week = 2 to get the schedule for Tuesday for example.
Each cell contains the name of the course and room.
This also defys the laws of normalization. You should always have no more than one value per "cell".
Really need the logic on how to get this started (i.e. what data types should I use )
Use the most intuitive type. When you store a number choose integer, when storing few characters choose varchar(n), when using lots of characters use text and so on...
I would create it this way where it is normalized and gives more chance to expand this app further.
Tables (attributes):
timeslots(id, start_time, end_time)
subjects(id, name)
timetable(timeslot_id, subject_id)
I'm trying to create a weekly (Monday - Sunday) schedule/agenda, similar to Google Calendar, using mySQL where users are able to fill out and display a schedule for what tasks they have at some day during some hour interval. For example a user task could store in the schedule as
Username | Day | Time | Task
Jimbob, Tuesday, 13:00, Eat super delicious spaghetti.
I'm wondering what is the best way to design the tables?
I could create a table for every day of the week, or have one big table that will store info for any day of the week. But what if I have a million users, would one big table be a performance issue?
Also, for the field of the tables I was planning to make one row store only one task for each hour, but I could also store all the tasks for each hour of the day. The latter could result in a lot of null values and take up more memory, but if the users fill out a lot of the calendar it seems like it could reduce a lot of rows, and redundant username entries. It also makes it easier to print out the schedule. Any thoughts?
Username | Hour | Task|
or
Username | 12am |Task1 | 1am | Task2 | 2am ....
Thanks.
The best way to do this, imo, would be to have two tables: one for users and one for tasks.
Users would have a user ID, a username plus whatever else.
Tasks would have the date and time, the description of the task, a task ID and the user ID of the user whose task it is. You shouldn't make a table storing each day of the week since you can just query the dates of the tasks. This is how you should design the tables. The actual calendar and the queries should be done in PHP or whatever you want to use for it.
Another answer shows how to set a default timestamp. However, it updates only the entry you edit. I was wondering if there is another way that would edit, let's say, the current year in all the entries.
For example, my database has 2 entries that were inserted in the year 2011, so the current date column for the 2 entries would be 2011. I would like to make this column update to 2012 when a new user is inserted, which means now there would be 3 entries and the current year column for all 3 entries would be 2012.
Is this possible?
My main objective is to calculate age.
You really don't need to - and should NOT - store the current year in a table's column (and possibly in several million rows) - unless you are writing a Star Trek application where some characters live in 2012 and others in 42012 (in other words if the "current year" is not the same for all).
You can always use this in your computations:
YEAR( CURRENT_DATE() )
If you store the user's birthdate as a DATE column then you can calculate their age. These calculations range from the "good 99%' of the time, to the good for everyone including leap year babies