There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
You can also find further discussion and get answers to your questions over in Language Help.
Agree with a comment or answer? Like () to up-vote the contribution!
If I get this right, after looking at the cheatsheet 'SQL for Back-End Development, the UNIQUE statement used in this exercise is different from the one used for Column Constraints.
On step 2 of the exercise, it says that we want to ensure:
attendees (identified by attendee_id ) are registered for only one talk at a time.
Regarding the Column Constraints on the cheatsheet, it mentions:
UNIQUE columns have a different value for every row.
My question is how they behave differently.
For example, if on step 2 of the exercise, I edited the statement as follows:
CREATE TABLE registrations (
id integer NOT NULL,
attendee_id integer UNIQUE NOT NULL,
session_timeslot UNIQUE timestamp NOT NULL,
talk_id integer NOT NULL,
____ (____, ____)
);
Does this mean that every attendee_id and session_timeslot should be different for each row?
Also, the way the current solution is proposed, do we want to ensure that every session_timeslot does not include the same attendee_id more than once?
A unique constrain means the value can only occur once. So if you do this:
attendee_id integer UNIQUE NOT NULL,
an attendee can’t attend multiple sessions/talks. Lets say your an attendee, and have id of 1, then 1 can only occur once in the entire registrations table (attendee_id field)
what you are looking for is a unique together constrain, which mean we can have:
attendee_id talk_id
1 1
1 2
2 1
2 2
attendee 1 and 2 can attend talk 1 and 2. That is totally fine. but with a unique together constrain would not allow the following:
attendee_id talk_id
1 1
1 1
given the combination is not unique.
oh, the constrain seems to be on session_timeslot (not talk_id), but the same idea/concept still applies.
Showing the examples is a good start but there is a significant difference when timeslot and talk_id are interchanged. Look at the sample below. I’ll substitute descriptive values for integer id’s.
Attendee Timeslot
Bob 1:00 PM
Bob 2:00 PM
Alice 1:00 PM
Alice 2:00 PM
Alice 2:00 PM
Bob 3:00 PM
The table above is good except except for one line. Bob Can attend 3 sessions because the sessions are all for different time slots. Alice can attend two different session, one at 1:00 and another at 2, but the 5th record is not allowed. She cannot attend two sessions at once. She cannot be at two places at once. In other words all combinations of attendee and timeslot must be unique. If the attendee and talk_id are combined, then what is enforced is the attendee can’t attend the same talk more than once, even if it is done for different time slots.
) below.
) to up-vote the contribution!