The problems with file-based systems
Data redundancy, inconsistency, isolation, integrity, atomicity and concurrency problems — the exact failures a DBMS was invented to fix.
Two notebooks, one truth
Imagine a school keeps a student's address in two different notebooks: one in the library register, one in the fees register. The student moves house and tells the fees clerk, who updates the fees notebook. Nobody tells the librarian. Now the school has two different addresses for the same student, and no way to know which one is right.
This is not a hypothetical — it is exactly what happens inside real companies that store data in scattered files instead of one managed system. This lesson names each specific failure so that, later, we can point at the DBMS feature that fixes it.
Data redundancy and inconsistency
Redundancy means the same fact is stored in more than one place. It happens naturally when different departments keep their own files: sales keeps customer addresses, billing keeps customer addresses, support keeps customer addresses.
Redundancy wastes storage, but the real danger is inconsistency — when the copies disagree, like the two notebooks above. There is no automatic way, in a pile of independent files, to know which copy is current.
More copies of the same fact floating around means more chances for exactly one of them to get updated while the others are forgotten.
Difficulty accessing data
In a file-based system, every new question you want answered often needs a brand new program written specifically for it. Want "all customers who bought something last month and live in Delhi"? If nobody wrote a program for that exact combination before, someone has to write new code, test it, and run it — for a question a database with a query language answers in one line.
Data isolation
Related data often ends up scattered across files in different formats — one written by an old accounting program, one in a spreadsheet, one in a plain text export. Data isolation is the difficulty of pulling related facts together when they are trapped in incompatible formats, even though logically they belong together.
Integrity problems
Integrity means the data obeys the rules of the real world it represents — an age should never be negative, a student ID referenced in a grades file should actually exist in the students file. In plain files, these rules live only in the heads of the programmers who write each individual program. Every program has to remember to check them, and it only takes one program that forgets for bad data to slip in.
Atomicity problems
Consider transferring money between two bank accounts stored in a file: subtract from account A, then add to account B. What happens if the computer crashes exactly between those two steps?
Money has vanished — not stolen, just lost to an incomplete operation. An operation that must happen either completely or not at all is called atomic. File systems, on their own, give you no atomicity guarantee.
Concurrent access anomalies
If two people can open and edit the same file "at the same time," the second person to save can silently overwrite the first person's changes with no warning. This is called a lost update, and it's one of several problems that show up whenever multiple users touch shared data simultaneously — we will study this family of problems in depth in Module 7.
Security problems
Files typically offer all-or-nothing access — if a program can open the file at all, it can usually read or change everything in it. There is no simple way to say "the fees clerk can edit fee amounts but only view addresses, and cannot see grades at all."
Common mistakes
- Thinking these are "old" problems that no longer matter. Every one of these failure modes still happens today, in spreadsheets, ad-hoc scripts, and systems that skip a real DBMS to save time early on.
- Believing redundancy is always bad. Some redundancy, carefully controlled (like backups or caches), is intentional and useful. The dangerous kind is uncontrolled redundancy where nothing keeps the copies in sync.
- Assuming atomicity is only about money. Any multi-step update — creating a user account plus a matching profile row, booking a seat plus updating a seat counter — has the same "what if it crashes halfway" risk.
Summary
File-based systems fail in specific, well-understood ways: redundant and inconsistent copies of the same fact, hard-to-answer new questions, scattered incompatible data, unenforced integrity rules, non-atomic multi-step updates, unsafe concurrent edits, and coarse security. Every module in this course maps to fixing one or more of these: the relational model and normalization fix redundancy and integrity, SQL fixes access difficulty, and transactions fix atomicity and concurrency. The next lesson introduces the DBMS itself and shows, feature by feature, how it answers each problem named here.