Introduction
Back in the 1990s and early 2000s, many enterprise applications followed a structured approach:
📌 “Keep all SQL logic centralized in a stored procedure layer.”
(At least many of the projects I worked on between mid 1990s and Mid 2000s, used some form of this pattern)
Why was this done?
- Performance – Stored procedures run inside the database, reducing network overhead.
- Security – Direct table access was restricted, preventing unauthorized data manipulation.
- Maintainability – Business logic was centralized, making updates easier.
This article explores:
- The history of stored procedures.
- Pros and cons of this approach.
- Alternative methods for handling CRUD operations.
- How to generate CRUD stored procedures for MySQL, SQL Server, and PostgreSQL using Python.
The History of Stored Procedures
Before modern ORMs (Object-Relational Mappers) like Entity Framework, SQLAlchemy, and Hibernate, database interactions were done using raw SQL queries.
Pre-Stored Procedures Era
- Developers embedded raw SQL statements in application code.
- Code and database logic were tightly coupled.
- Query execution was slow because every request required parsing and optimization.
The Stored Procedure Revolution (1990s - Early 2000s)
- SQL vendors introduced stored procedures as precompiled database scripts.
- These scripts were stored inside the database itself, leading to faster execution and better security.
- Many enterprise applications relied heavily on stored procedures for CRUD operations.
Further Reading: Stored Procedure - Wikipedia
Why Use Stored Procedures for CRUD?
A typical CRUD operation using stored procedures follows this structure:
CRUD Operation | Example Stored Procedure |
---|---|
Create | usp_CreateUser |
Read | usp_GetUserById |
Update | usp_UpdateUser |
Delete | usp_DeleteUser |
Advantages of Using Stored Procedures
Feature | Benefit |
---|---|
Performance | Precompiled execution improves query speed. |
Security | Restricts direct table access, reducing SQL injection risks. |
Centralized Logic | Business logic stays in the database. |
Reduced Network Traffic | Only procedure calls are sent to the database. |
Disadvantages of Using Stored Procedures
Issue | Drawback |
---|---|
Hard to Debug | Debugging SQL inside the database is challenging. |
Version Control Issues | Harder to track changes compared to application code. |
Limited Portability | Vendor-specific SQL syntax makes migration difficult. |
Slower Development | Writing and maintaining stored procedures takes effort. |
Automating CRUD Stored Procedure Generation with Python
To simplify CRUD procedure creation, we can automatically generate stored procedures for MySQL, SQL Server, and PostgreSQL using Python.
How we used to do this
We would usually have a gen directory and an edited .
Every time you changed the schema you regenerate.
If you tweak or edit a stored procedure, you copy it to the edited directory first.
Then when you apply the stored procedures to to the database , apply the generated first , then the edited.
Sometimes we would generate LIST stored procedures and sometimes views , it just depended on the needs pod the application we were building.
Project Structure- The General idea
|
|
Example: Auto-Generate CRUD Stored Procedures from Live MySQL Database
This Python script connects to a live MySQL database, retrieves the schema, and generates CRUD (Create, Read, Update, Delete) stored procedures for each table found in the database.
Prerequisites
Install Python Dependencies:
1
pip install mysql-connector-python
Update Database Credentials in the script (
your_username
,your_password
,your_host
,your_database
). (and then email the script to me with the public ip of your server……)
Python Script to Generate CRUD Procedures
|
|
Explanation
- The script connects to a MySQL database and retrieves all table names.
- It then fetches the column details, identifying the primary key for each table.
- It generates four stored procedures for each table:
sp_create_{table_name}
: Inserts a new record.sp_read_{table_name}
: Retrieves a record by primary key.sp_update_{table_name}
: Updates a record based on primary key.sp_delete_{table_name}
: Deletes a record by primary key.
- The generated stored procedures are printed to the console.
- We used to generate one file per operation per table, but you can do it however you like
- See the project structure diagram above for ideas and how to structure
Notes On The Python Script
- Primary Key Requirement: The script requires that each table has a primary key. If a table lacks one, it is skipped.
- Customization: You may probably should modify the script to include additional constraints, logging, or transaction management.
- Execution: Redirect the script’s output to a SQL file or copy-paste it into a MySQL console to execute the stored procedures.
Key Takeaways
- Stored procedures enhance performance and security, but increase maintenance complexity.
- Python automation can simplify stored procedure creation.
- Alternative methods like ORMs (Entity Framework, SQLAlchemy) provide more flexibility.
- Views and indexing can improve stored procedure efficiency.