Week 3 Reading Questions

Tip

💡 Pro-tip: ✨ Start here! Before you begin the reading, take a quick look at these questions. They’ll point you toward the key ideas to watch for.

📚 As you read, keep them in the back of your mind—they’re like little mental sticky notes.

✅ After you’re done, come back and quiz yourself. Can you answer them without peeking? That’s how you know you’ve nailed the core concepts!

Question 1

In the Books table, why would we add an index on the Author column?

A. To reduce data redundancy

B. To ensure uniqueness

C. To enforce a foreign key relationship

D. To speed up searches for books by author

Click to see answer

Adding an index on the Author column improves query performance when filtering or searching by author name. By adding an index to this column, you will be able to search for a book by a certain author in log(N) time instead of linear time (N). Indexing doesn't affect data structure or relationships, but makes lookups faster.

Question 2

You are designing a courses and students schema where each student can enroll in multiple courses, and each course can have multiple students. How should you represent this relationship?

A. Add course_id to the students table

B. Add student_id to the courses table

C. Create an enrollments table with student_id and course_id as foreign keys

D. Combine students and courses into one table

Click to see answer

✅ Correct Answer: C. Create an enrollments table with student_id and course_id as foreign keys. This is a many-to-many relationship — one student can be in many courses, and each course can have many students. This structure will allow flexible linking and avoids data duplication.

Question 3

SQL query with RLS policy:

CREATE TABLE Books (
  Book_ID INT PRIMARY KEY,
  Title VARCHAR(255),
  Author VARCHAR(255),
  Genre VARCHAR(50),
  Added_By UUID
);

-- RLS Policy:
CREATE POLICY "Users can manage their own books"
ON Books
FOR ALL
USING (auth.uid() = Added_By)
WITH CHECK (auth.uid() = Added_By);

Scenarios: A. A user tries to update the Genre of a book they added

B. A user runs SELECT * FROM Books; and sees fewer results than expected

C. A user tries to insert a new book without including the Added_By column

D. A user tries to delete a book that was added by someone else

E. A user updates the Title of a book they added, but leaves out the Added_By column in the update

Possible Outcomes:

1. Update succeeds — user owns the row, and both RLS checks pass
2. Insert fails — Added_By is null, so WITH CHECK fails
3. Query returns only rows the user added — others are hidden by USING
4. Delete fails — USING check blocks deletes unless the row was added by the user
5. Update succeeds — omitting Added_By is allowed as long as it doesn’t change
6. Update fails — WITH CHECK requires Added_By in every update query
7. Insert succeeds — RLS only applies to updates and deletes
8. Query fails — RLS blocks any row-level access unless the user has admin privileges

Click to see answer

The RLS policy explained:

Clause	What it controls	What it does in this policy
FOR ALL	Types of operations (SELECT, INSERT, etc.)	Applies to everything
USING	Which rows the user can read/update/delete	Only rows where Added_By = current user’s auth.uid()
WITH CHECK	Which rows the user can insert/update	Only if they’re adding/updating with their own auth.uid()

Scenarios and Outcomes:

Scenario	Outcome	Explanation
A. A user tries to update the Genre of a book they added	✅ Update succeeds	The user owns the row, so USING allows the update. Since Added_By isn’t changing, WITH CHECK also passes
B. A user runs SELECT * FROM Books;	✅ Query returns only user’s rows	USING (auth.uid() = Added_By) filters rows, so they only see their own
C. A user tries to insert without Added_By	❌ Insert fails	WITH CHECK fails because Added_By is null and doesn’t match auth.uid()
D. A user tries to delete another’s book	❌ Delete fails	USING blocks delete — user can only delete rows where they are Added_By
E. A user updates Title, omits Added_By	✅ Update succeeds	The update doesn’t change Added_By, so WITH CHECK still passes

Question 4

If we ask Cursor to set up a NextJS API endpoint to generate trivia questions:

1. What files in the trivia app will be changed?
2. What if we want to add a button on the front-end to test the endpoint?
3. What if we want to add the ability to save the questions generated into a Supabase database table?

Click to see answer

1. app/api/trivia/route.ts: This is where the back-end functionality is encoded. Since we’re setting up a NextJS API endpoint, this will live on the back-end.

2. app/protected/TriviaButton.tsx: This is where the trivia button will be pressed. It is a front-end page that is safeguarded under user authentication.

3. app/api/trivia/route.ts: The questions will be saved on the backend. Thus, it makes sense for this saving to take place after the trivia questions are originally generated.