Back-end

What is the Back-end?

The back-end of a website is where data is stored, processed, and managed. To understand back-end programming, we need to understand how data works, how it's stored, and how it's managed by systems and software.

At its core, data refers to structured pieces of information that are collected and maintained. This could include user profiles, product inventories, blog posts, weather logs, or almost anything that needs to be saved for later use. The data must be kept up to date and accessible, as most applications rely on being able to quickly retrieve and process it to serve users in real time.

Once you start collecting and storing data in a meaningful way, you build what is called an archive. An archive, in this context, is essentially a collection of data stored in a database. A well-structured archive allows for CRUD operations efficiently.

Back-end programming involves writing the logic and functionality that allows users to interact with your data securely and efficiently. Whether you're building APIs, designing database schemas, or writing queries to update user records, you're enabling the invisible but crucial part of a web application.

In essence, back-end programming makes modern web and mobile apps work, not just look good. It ensures that when someone hits "submit" or "search," something intelligent happens behind the scenes.

Databases and DBMS

The DBMS is the software responsible for handling and organizing data in a database. Think of it as the middleman between your application and the actual data storage. The DBMS:

  • Manages how data is stored and retrieved
  • Handles data security and access controls
  • Runs continuously on a server to allow real-time interaction
  • Supports backups and data integrity

When we say a system "has a database," we're really talking about a computer (called a database server) running a DBMS. If the database system specifically manages relational data (data organized in tables with defined relationships), it's known as a RDBMS.

Requests and Queries

When a user interacts with an application by searching for a product or logging in, the application sends a request to the back-end. In the context of databases, especially when retrieving information, these requests are known as queries. A query asks the database to "give me all the products that cost less than $50" or "find the user whose email is xyz@example.com." The DBMS processes this query, looks through the database, and returns the requested data.

Tables, Rows, and Columns

Databases, especially relational ones, organize data using a table-based structure, which consist of tables and their rows and columns. This format allows databases to be highly organized, flexible, and efficient to search through.

  • Table: A container that holds related data (e.g., a table named Users might store all registered users).
  • Row: A single record in the table (e.g., one user's profile with their name, email, etc.).
  • Column: A specific field or attribute (e.g., email or date_of_birth) that appears in every row.

The Schema

The schema defines the structure of the database. It acts like a blueprint, outlining:

  • What tables exist
  • What columns each table contains
  • The data types for each field (e.g., text, date, number)
  • How tables are related

This blueprint can be visualized in diagrams, often referred to as ERDs, and it helps developers and systems understand how the data is laid out.

Relational vs Non-Relational

Databases come in different types, with two major categories:

  • Relational Databases (SQL): These use structured tables with rows and columns, and enforce relationships between data (e.g., a Users table linked to an Orders table by user ID). Examples include MySQL, PostgreSQL, and SQLite.
  • Non-Relational Databases (NoSQL): These do not use tables and often store data in more flexible formats like JSON, key-value pairs, or documents. They are useful for unstructured data and rapid development. Examples include MongoDB, Firebase, and Redis.

Choosing between these depends on the project's needs, scale, and data complexity.