How do models and the ORM work?

Question

Accepted Answer

A **model** is a Python class that defines the structure of your data — each model maps to a database table, and each attribute to a column. The **ORM (Object-Relational Mapper)** lets you interact with the database using Python objects and methods instead of writing raw SQL.

## Defining a model

```python
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)       # → VARCHAR column
    body = models.TextField()                        # → TEXT column
    published = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)  # set on creation
    views = models.IntegerField(default=0)

def __str__(self):
        return self.title                            # readable representation (admin, shell)
```

Each model field maps to a database column with an appropriate type. Running migrations creates the corresponding table — you never write `CREATE TABLE` yourself.

## CRUD with the ORM (no SQL)

```python
# CREATE
article = Article.objects.create(title="Hello", body="...")

# READ — query with Python methods
Article.objects.all()                            # all rows → SELECT *
Article.objects.get(id=1)                         # one row by primary key
Article.objects.filter(published=True)            # WHERE published = true
Article.objects.filter(title__icontains="django") # WHERE title ILIKE '%django%'
Article.objects.exclude(views=0).order_by("-created_at")  # complex queries, chained

# UPDATE
article.title = "Updated"
article.save()
Article.objects.filter(published=False).update(published=True)  # bulk update

# DELETE
article.delete()
```

The ORM translates these Python calls into SQL automatically. Field lookups (`__icontains`, `__gte`, `__in`, etc.) express WHERE conditions Pythonically.

## Why an ORM? Benefits and trade-offs

```text
✓ Write database code in Python — no SQL, more readable, less error-prone
✓ Database-agnostic — the same code works on PostgreSQL, MySQL, SQLite
✓ SECURITY — parameterized queries by default → prevents SQL injection
✓ Integrates with migrations, admin, forms (define the model once)
⚠️ Trade-off: can generate inefficient queries (e.g. N+1) if used carelessly —
   sometimes you need select_related/prefetch_related or raw SQL for complex cases
```

## Models are the single source of truth (DRY)

```text
One model definition drives: the database schema (migrations), the admin interface,
ModelForms, and serializers (DRF) — define it once, reuse everywhere.
```

## Why it matters

Models and the ORM are central to Django — they're how you define and work with your application's data, which is the heart of most web applications.

Understanding them is essential everyday knowledge: models define your data structure (mapping classes to tables, attributes to columns) and serve as the **single source of truth** that drives the database schema, admin interface, forms, and API serializers (the DRY philosophy).

The ORM lets you write database operations in clean, readable **Python instead of SQL**, with major benefits: database portability (the same code runs on different databases), tight integration with the rest of Django, and crucially **security** (it uses parameterized queries by default, preventing SQL injection).

Knowing how to define models with appropriate fields, perform CRUD operations, and query with the ORM's lookup syntax is fundamental to building any Django application.

Equally important is awareness of the ORM's **trade-off** — that convenient queries can become inefficient (the N+1 problem) without care — which leads to optimization techniques.

The model/ORM layer is where Django applications spend much of their logic, making it core, must-master material.