Which Python ORM is better between Django and SQLAlchemy

What is ORM?

Before introducing the differences between Python's ORM frameworks (Django and SQLAlchemy), we must first ensure that we fully understand the purpose of the ORM framework.

ORM stands for Object Relational Mapping. Let's take a look at these three words in turn, which exactly explain the usefulness of ORM in a real environment:

● Objects – This part represents objects and programming languages ​​using the framework, such as Python.

● Relationship – This part represents the RDBMS (Relational Database Management System) database being used. These include many popular relational databases, and you may be using the following databases — MSSQL, MySQL, Oracle Database, PostgreSQL, MariaDB, PerconaDB, TokuDB. What most relational databases have in common is their relational structure (tables, columns, keys, constraints, etc.).

● Mapping – The last part represents the bridge and connection between the objects and data tables in the first two parts.

So it can be concluded that ORM is to connect programming languages ​​and databases in order to simplify the process of creating applications that rely on data.

Comparison between Django and SQLAlchemy Activity Recording vs Data Mapping

Django ORM Implemented using active records - this implementation can be seen in most ORMs. Basically it can be said that every row in the database is directly mapped to an object in the code, and vice versa. ORM frameworks (like Django) don't need to pre-define the schema in order to use properties in code, they just need to use them because the framework can "understand" the structure by looking at the database schema. Additionally, it is possible to just save the record to the database as it is also mapped to a specific row in the table.

SQLAlchemy Implemented using data mapping - When implemented this way, there is a gap between the database structure and the object structure (they are not 1:1 like the active record implementation). In most cases, an additional persistence layer must be used to maintain interaction with the database (such as saving objects). So you can't just call the save() method when implemented with active records (opposition), but on the other hand, the code does not need to know about the operation of the entire relational structure in the database, because there is no direct relationship between the code and the database.

So who wins among them? nothing. It depends on what you want to achieve. I believe that if your application is mostly a CRUD (Create, Read, Update, Delete) program without using difficult and complex rules between different data entities, then you should adopt the Active Record implementation (Django). It will help you set up an MVP for your product easily and quickly without any difficulty. If there are many "business rules" and constraints, it is better to use a data mapping model because it does not tie and force strict compliance with the activity record considerations.

Use complex queries

In some cases, Django and SQLAlchemy can be used simultaneously. The main use case I've seen many times in real life is Django for all the regular CRUD operations and SQLAlchemy for more complex queries, usually read-only queries.

For more information and examples on this, check out the BetterWorks Engineering Blog (we have no affiliation, but we like their blog anyway).

Primary key automatically generated

Another difference between the two frameworks is that Django can automatically create primary keys for tables, but SQLAlchemy cannot. Primary keys must be created manually for each table. Weighing the pros and cons - which framework do you think best conforms to the primary key of a table? This can be determined at your own discretion based on the team's knowledge and experience.

Automatic submission

By default, Django will automatically submit, but SQLAlchemy will not. Autocommit affects how you use the framework (transactions, rollbacks, etc.).

Supported databases

Django and SQLAlchemy both work with MySQL, PostgreSQL, Oracle and SQLite. If you are using MSSQL, you should use SQLAlchemy as it fully supports MSSQL and you can also find more related information and documentation.

learning curve

There is a common view on the Internet that Django is easier to learn. This is obvious since it is usually used for use cases that are not particularly complex. Therefore, you should consider how much effort you are willing to invest in learning the framework and cross-learning with SQLAlchemy to gain more flexibility (assuming you really need it).

Community scale

There is no doubt that SQLAlchemy has the largest community among Python ORM frameworks. If community is important to you (and I think it should be), SQLAlchemy should be your choice. This doesn't mean that you can't find any help for other frameworks, such as Django. You can also get bug fixes, answers to questions and other needed help from StackOverflow, but the odds are only higher than with SQLAlchemy.

performance

I think it is irresponsible to just write (X is faster than Y) here. Since ORMs have so many features and capabilities, and they differ in each framework, it would be difficult to draw conclusions. In my experience, the way you use framework features can have a huge impact on the overall performance of the data layer in your application. Therefore, I suggest not to choose a framework based on performance, but to learn how to utilize the framework rationally.

If you are using raw SQL queries in an ORM framework, using Jooq, or just part of the query without using ORM, you can learn about the EverSQL query optimizer, which may be the easiest way to optimize any query.

Summarize

In any comparison, I think it’s best to leave the decision-making power back to the reader. Each use case is different and different technologies may be more suitable. Take a look at the differences noted above and let us know what you decide.

The above is the detailed content of Which Python ORM is better between Django and SQLAlchemy. For more information, please follow other related articles on the PHP Chinese website!