0% found this document useful (0 votes)
10 views4 pages

Implicit Joins Subqueries: Fully Atomic Single-Threaded

The document discusses the use of Django ORM for database interactions, highlighting implicit joins, explicit subqueries, and window functions. It explains the principles of atomicity, consistency, isolation, and durability in database management, contrasting object-oriented programming with relational databases. Additionally, it covers the advantages and disadvantages of ORM, including connection pooling techniques to optimize database connections for better performance.

Uploaded by

Erdey Syoum
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views4 pages

Implicit Joins Subqueries: Fully Atomic Single-Threaded

The document discusses the use of Django ORM for database interactions, highlighting implicit joins, explicit subqueries, and window functions. It explains the principles of atomicity, consistency, isolation, and durability in database management, contrasting object-oriented programming with relational databases. Additionally, it covers the advantages and disadvantages of ORM, including connection pooling techniques to optimize database connections for better performance.

Uploaded by

Erdey Syoum
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

In Django, implicit joins are handled automatically via double-underscore lookups in queries,

while explicit subqueries are managed using expressions like Subquery, OuterRef, Exists, and
Count.

Django ORM supports window functions (since Django 2.0+, fully with PostgreSQL) via
Window, DenseRank(), Rank(), RowNumber(). These are perfect for rankings and will be much
more efficient than fetching all data and processing in Python.

Redis is fully atomic at the command level. All Redis commands run atomically. Because Redis is single-threaded,
no two commands interleave. If 1,000 clients run INCR simultaneously, Redis processes them one-
by-one in correct order with zero race conditions.

Atomicity: complete or rollback to the previous state.


Consistency: Maintain data integrity e.g not null, primary key, foreign key, unique etc. The
database should be correct.
Isolation: serializable
Durability: changes made to the database (transactions) that are successfully committed will
survive permanently, even in the case of system failures.

Redis maintains consistency within the context of simple operations, but does NOT enforce:
foreign keys, Constraints, schema validation, relational integrity, transactional logic across
complex queries

Objects are equal if they are the same instance in memory. RDBMS → Rows are equal if their
primary key values match. OOP → Objects can reference each other directly (like pointers).
RDBMS → Relationships use foreign keys and joins. Inheritance: OOP → Natural (class
Employee can inherit from Person). RDBMS → No native inheritance; you must simulate it with
extra tables or duplication. Data types: OOP → Rich types (objects, lists, nested structures).
RDBMS → Primitive atomic values (strings, numbers, dates). Navigation: OOP → Navigate by
accessing object attributes ([Link]). RDBMS → Navigate by running
JOIN queries. Sometimes you will have an object model which has more classes than the number
of corresponding tables in the database.

Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a
programming technique for converting data between incompatible type systems using object-
oriented programming languages. This creates, in effect, a "virtual object database" that can be
used from within the programming language.

In object-oriented programming, data-management tasks act on object-oriented (OO) objects


that are almost always non-scalar values. Many popular database products such as SQL database
management systems (DBMS) can only store and manipulate scalar values such as integers and
strings organized within tables.

The programmer must either convert the object values into groups of simpler values for storage
in the database (and convert them back upon retrieval), or only use simple scalar
values within the program. Object-relational mapping implements the first approach.

right now I am reading orm and I think relational databases uses atomic values in each field but
in oop the smallest thing is object and it is mostly a combination of values right?

With ORM (Object Manipulation) you write object manipulation code → work with objects like
in OOP, ORM translates it into SQL for you.

Compared to traditional techniques of exchange between an object-oriented language and a


relational database, ORM often reduces the amount of code that needs to be written.
Disadvantages of ORM tools generally stem from the high level of abstraction obscuring what is
actually happening in the implementation code. Also, heavy reliance on ORM software has been
cited as a major factor in producing poorly designed databases. Object-Relational Mapping
(ORM) is a technique that lets you query and manipulate data
from a database using an object-oriented paradigm.

An ORM library is a completely ordinary library written in your language of choice that
encapsulates the code needed to manipulate the data, so you don't use SQL anymore; you
interact directly with an object in the same language you're using.

Using ORM saves a lot of time because:


DRY: You write your data model in only one place, and it's easier to update, maintain, and reuse
the code. It forces you to write MVC code, which, in the end, makes your code a little cleaner.
You don't have to write poorly-formed SQL (most Web programmers really use it, because SQL
is treated like a "sub" language, when in reality it's a very powerful and complex one).
Sanitizing; using prepared statements or transactions are as easy as calling a method. Using an
ORM library is more flexible because: It fits in your natural way of coding (it's your language!).
It abstracts the DB system, so you can change it whenever you want. The model is weakly bound
to the rest of the application, so you can change it or use it anywhere else.

But ORM can be a pain: you have to learn it, and ORM libraries are not lightweight tools; You
have to set it up. Performance is OK for usual queries, but a SQL master will always do better
with his own SQL for big projects. It abstracts the DB. While it's OK if you know what's
happening behind the scene, it's a trap for new programmers that can write very greedy
statements, like a heavy hit in a for loop.

Database Connection Pooling?

Connection Pooling means keeping a pool of open database connections so your application can
reuse them instead of creating a new connection for every request.

Without pooling:

Every request creates a new connection.

Creating a DB connection is slow (100–300 ms).

Sudden traffic causes your database to become overloaded.

You get errors like:

"too many connections"

"connection refused"

"server closed the connection unexpectedly"

With pooling:

Connections are reused → faster requests

Database load is stable

Handles many users efficiently

Saves memory & CPU

Pooling is not done by Django itself.

It is done by:

Your database driver (psycopg / psycopg2)

PostgreSQL’s psycopg driver supports connection pooling.

2. External pooling tools


These are common in production:

Pooler Purpose
PgBouncer Most popular PostgreSQL pooler; very lightweight
Pgpool-II Load balancing, replication + pooling
Gunicorn / Uvicorn workers Django + ASGI needs pooling for concurrency

WebSocket keeps one connection open to handle many messages,

DB pooling keeps a few connections open to handle many requests.

You might also like