Primary Key Identification

Think about how you tell two students apart in a classroom. If you call out "Rahul," there might be three Rahul's. But if you say "Rahul Sharma, roll number 12," you've pointed to exactly one person. That unique identifier — the roll number — is doing the job of a primary key.

The Everyday Intuition

Every collection of things needs a way to refer to each item without confusion. In a library, every book has a unique accession number. In a bank, every account has an account number. In a school, every student has a unique admission number. These are not random — they are deliberately chosen so that no two items share the same identifier.

This is the core idea: a primary key is a single attribute (or a combination of attributes) that uniquely identifies each record in a table. No two rows can have the same primary key value, and no primary key can be empty (null).

The Precise Meaning

In database terms, a primary key serves two non-negotiable rules:

• Uniqueness — every value in the primary key column must be different from every other value. If you have 100 students, you need 100 distinct roll numbers.
• Non-null — every record must have a primary key value. You cannot have a student with "no roll number."

A primary key can be a single column, like a student ID. Or it can be a composite key — two or more columns taken together to create uniqueness. For example, in a table recording which books students have borrowed, neither "Student ID" alone nor "Book ID" alone is unique (a student borrows many books; a book is borrowed by many students over time). But the combination of "Student ID + Book ID + Date Borrowed" together can be unique.

Why It Matters

Without a primary key, you cannot reliably update or delete a specific record. Imagine a school database where two students have the same name "Ananya Sharma." If you try to delete "Ananya Sharma," the database has no way to know which one you mean. With a primary key, you say "delete student with roll number 45" — and it's unambiguous. …

MySQL Data Types: Storing Information the Right Way

Think of a library. Every book has a specific place, and the librarian knows exactly what kind of item each shelf holds — novels go here, reference books there, magazines in a separate rack. If you shoved a dictionary into the magazine rack, it wouldn't fit, and finding it later would be a mess.

MySQL works the same way. When you create a table to store data, you must tell MySQL what kind of data each column will hold. This is called a data type. It's the rule that says: "This column will only ever contain whole numbers" or "This column will only ever hold short text." Getting this right from the start is what keeps your database organised, fast, and reliable.

Why Data Types Matter

Without data types, MySQL would have no idea how much space to reserve for each piece of information, or how to sort and compare values. If you stored a phone number as a number, MySQL might try to add it to another number — which makes no sense. If you stored a date as plain text, MySQL couldn't tell you "which records are from last month."

Every column in every table must have a data type. It's not optional. And choosing the right one is a skill you build with practice.

The Main Families of Data Types

MySQL offers many data types, but they fall into a few broad families. For a commerce or humanities student, these are the ones you'll use most often.

1. String (Text) Types

These store words, sentences, names, addresses, product descriptions — anything made of letters, digits, or symbols.

• CHAR — Fixed-length text. If you say CHAR(10), every entry takes exactly 10 characters, even if you only store "Hi". MySQL pads the rest with spaces. Use this when you know the length will always be the same, like a state code ("MH", "DL", "KA").
• VARCHAR — Variable-length text. If you say VARCHAR(100), an entry like "Mumbai" uses only 6 characters of space, not 100. This is the workhorse for names, addresses, email IDs, and most short-to-medium text.
• TEXT — For long paragraphs, like product reviews or article bodies. It can hold up to about 65,000 characters. There are larger variants (MEDIUMTEXT, LONGTEXT) for very long content.

2. Numeric Types

These store numbers — but not all numbers are the same.

• INT — Whole numbers (integers) from roughly -2 billion to +2 billion. Use this for quantities, IDs, years, counts. Most of the time, INT is what you need.
• DECIMAL — Numbers with decimal places, where exact precision matters. Think prices, tax rates, percentages. DECIMAL(10,2) means 10 digits total, with 2 after the decimal point — perfect for ₹1,234.56.
• FLOAT and DOUBLE — Approximate decimal numbers. Faster for scientific calculations, but can have tiny rounding errors. Avoid these for money.

3. Date and Time Types

These store dates, times, or both — and MySQL understands them natively, so you can ask questions like "find all orders from last week."

• DATE — Stores a date only: '2025-04-10'. No time.
• DATETIME — Stores date and time together: '2025-04-10 14:30:00'. This is the most common choice for timestamps of transactions, registrations, or log entries.
• TIMESTAMP — Similar to DATETIME, but with a smaller range and automatic timezone conversion. Often used for "last updated" fields.
• YEAR — Just a four-digit year. Useful for birth years or academic sessions.

4. The Boolean Type

MySQL doesn't have a true/false data type in the way you might expect. Instead, it uses BOOLEAN or BOOL, which is really just a tiny integer — 0 means false, 1 means true. You'll use this for yes/no fields like "is_active", "has_discount", or "verified".

How to Choose: A Simple Rule

Ask yourself three questions about every piece of data you want to store:

1. Is it text, a number, or a date? That tells you the family.
2. How long or how big can it be? That tells you the specific type within the family. …