Database Design Mistakes Students Make

Bad Database Design Creates Bugs Everywhere Else

In student software projects, database problems often appear as frontend bugs, API bugs, or confusing test results. The form works, the route runs, but the stored data is duplicated, inconsistent, or impossible to query cleanly.

Good database design does not require a perfect enterprise schema. It requires clear entities, reliable keys, sensible relationships, and constraints that protect the rules of your system.

Mistake 1: Starting With Tables Before Entities

Before creating tables, list the things your system manages. These are usually entities:

• Student
• Course
• Enrollment
• Appointment
• Payment
• Submission

Each entity should represent one kind of thing. If a table name contains two concepts, such as student_course_teacher_details, it may be hiding several entities that should be separated.

Mistake 2: Duplicating the Same Data in Multiple Places

Duplicated data becomes inconsistent. If a student's email appears in five tables, what happens when the email changes?

Instead of copying fields, store the data once and reference it:

students(id, name, email)
courses(id, title)
enrollments(id, student_id, course_id)

The enrollments table links students and courses without repeating every student and course field.

Mistake 3: Using Weak Primary Keys

A primary key should uniquely identify one row. Names, emails, titles, and phone numbers are usually poor primary keys because they can change or collide.

Prefer stable generated IDs:

students(
  id integer primary key,
  name text not null,
  email text unique not null
)

The email can still be unique, but the internal ID remains the safest reference for relationships.

Mistake 4: Missing Foreign Keys

Foreign keys protect relationships. Without them, your database can contain an enrollment for a student that does not exist.

create table enrollments (
  id integer primary key,
  student_id integer not null references students(id),
  course_id integer not null references courses(id)
);

If your project database supports foreign keys, use them. They catch mistakes earlier than application code alone.

Mistake 5: Storing Lists Inside One Column

This looks convenient:

course_ids: "1,2,3"

But it is hard to query, validate, and update. A separate relationship table is cleaner:

enrollments(student_id, course_id)

If a field contains commas, multiple IDs, or repeated values, ask whether it should be a separate table.

Mistake 6: Designing Without Realistic Test Data

A schema can look fine with three perfect rows and fail with realistic data. Test with:

• Empty relationships
• Duplicate attempts
• Long names or titles
• Missing optional fields
• Users with multiple roles or records
• Records that should be deleted or archived

Realistic test data reveals whether your relationships and constraints actually match the system.

Mistake 7: Ignoring Query Requirements

Database design should support the questions your app needs to answer:

• Which courses is this student enrolled in?
• Which appointments are pending?
• Which projects have not been reviewed?
• Which submissions were created this month?

If a common screen requires awkward joins or repeated filtering in JavaScript, revisit the schema. The database should help answer core questions directly.

Getting Schema Feedback Before It Spreads

Database design problems are cheaper to fix before the API and UI depend on them. EduSupport's final-year software project mentoring and student code review can help students review schema choices, relationships, and query logic while keeping the project student-authored.