Why bother with an ORM if I already know SQL?

I get this question a lot. If you're comfortable writing SELECT * FROM users WHERE id = 1, using an ORM can feel like adding an unnecessary layer of abstraction. But here is the reality: managing raw SQL strings inside your Python code is a nightmare as your project grows. You end up with massive strings concatenated together, which is not only ugly but opens you up to SQL injection attacks if you aren't incredibly disciplined with parameterization.

The real magic of an ORM (Object-Relational Mapping) is that it solves the "impedance mismatch." Databases think in tables and joins; Python thinks in objects and attributes. An ORM lets you treat your database rows as Python objects. Instead of parsing a tuple returned by a cursor, you just access user.email. It makes your code cleaner, more maintainable, and often more portable across different database engines.

How does a Python class actually "map" to a database table?

Think of the ORM as a translator. It uses a mapping configuration to link the two worlds. In a typical Python ORM (like SQLAlchemy or Django), you define a class that inherits from a base model. This class acts as the blueprint for your table.

Let's say we're building a system to track a personal library. Here is how that mapping looks conceptually:

# This is a conceptual example of how ORM definitions look
class Book(Base):
    __tablename__ = 'books'
    
    # Class attributes define the table columns
    id = Column(Integer, primary_key=True)
    title = Column(String)
    author = Column(String)
    published_year = Column(Integer)

In this setup:

• The Class (Book) maps to the Table (books).
• The Class Attributes (title, author) map to the Columns.
• An Instance of the class (my_book = Book(title="The Hobbit")) maps to a single Row in that table.

Does using an ORM make my application slower?

The short answer is: yes, technically. There is a small amount of overhead because the ORM has to translate your Python method calls into SQL queries behind the scenes. For 90% of applications, this overhead is completely negligible compared to the time the database takes to actually execute the query.

However, the real "slowness" usually comes from how you use the ORM, not the ORM itself. I've seen developers accidentally write "N+1 queries," where they fetch a list of 100 books and then hit the database 100 more times to get the author for each book. If you were writing raw SQL, you'd just use a JOIN. Most ORMs have a way to do this (often called "eager loading"), but you have to be intentional about it. My advice? Use the ORM for the bulk of your work, but don't be afraid to drop down into raw SQL for that one hyper-optimized report that needs to crunch millions of rows.

📋 Practical Task

Designing a Movie Rental Catalog Schema

Imagine you are building a movie rental system. You need to track Movies, Customers, and Rentals (which links a customer to a movie and records the date).

Since we are focusing on the concepts of ORM mapping rather than a specific library's syntax, your task is to write a conceptual Python mapping for these three entities. For each class, you must define:

• The class name and the corresponding table name.
• At least three columns (attributes) with their data types (e.g., String, Integer, DateTime).
• A way to represent the relationship (e.g., a customer_id in the Rental class that points back to the Customer class).

Write your solution as a set of Python classes. Focus on how the data relates—ensure that the Rental class effectively acts as the bridge between a Customer and a Movie.