Walk me through your project's database design and why you made those choices.

Here's how I'd walk through my database design. My project had four main tables: users, orders, products, and order_items. The users table stores customer information like email and password hash. Each user can place multiple orders, so I have a one-to-many relationship there. The orders table has a user_id foreign key that references the users table. For products, I needed a many-to-many relationship with orders because one order can contain multiple products and one product can appear in multiple orders. So I created a join table called order_items with a composite primary key of order_id and product_id, plus a quantity column. That way I can link orders and products without duplicating data. I normalized the schema to third normal form to avoid repeating user data across multiple orders. For example, if a user's email changes, I only update it in one place. The trade-off is that fetching a complete order with all its product details requires joining three tables, which can be slow. In hindsight, I might denormalize by storing product names directly in the order_items table so I don't have to join the products table just to display order history. That would duplicate data but speed up the most common query. I also considered putting addresses in a separate table, but since most users only have one address, I kept it in the users table to avoid unnecessary joins.