Week 2 — PostgreSQL & TypeORM

Everything else in this week — keys, joins, TypeORM entities — is just more structure on top of tables and columns. Read raw SQL before you read decorators.

Keys are what turn separate tables into a connected schema. tickets.assignee_id pointing at users.id is the whole relationship this app is built around.

Before TypeORM writes any of this for you, know what the actual SQL looks like — it is what a Repository call or QueryBuilder produces under the hood.

This app’s core relationship — a ticket and its assignee — lives across two tables. A join is how you see both together in one query.

Before Nest or TypeORM enter the picture, understand what DATABASE_URL actually configures, why pooling exists, and what happens when an app misuses connections.

This is where the SQL-level concepts (URL, entities-as-tables, no synchronize) become one concrete Nest config object.

User and Ticket in this repo are the entities behind every users/tickets row you have already seen in raw SQL.

This is the layer that TicketsService actually uses — @InjectRepository(Ticket) gives it a Repository<Ticket>, wired up via TypeOrmModule.forFeature in the feature module.

This is the single most important backend habit in the course: schema changes are files you review, not something TypeORM infers silently.

This course’s seed script is exactly how admin@course.local and member@course.local (password123) get into a fresh database.

This repo has a real 1:N relationship (User ↔ Ticket) — 1:1 and N:N are covered here as patterns you will need for other features, shown as illustrative extensions of this same schema.

Repository/QueryBuilder calls outside a transaction each commit independently; TypeORM gives you an explicit way to group writes when that independence would be a bug.

Maps to Week 2 SQL + TypeORM. Use W3Schools SQL/PostgreSQL under /resources if you need query refreshers.