File Processing vs. the Database Approach

The problem the database approach was invented to solve

Before databases, each application owned its own private files, and the *description* of those files — field names, lengths, formats — was written directly into the application program's code. This is file processing, and it has five chronic disadvantages:

1. Program-data dependence. File descriptions are embedded *inside each program*. Change a file’s structure and every program that touches it must be found and edited.
2. Duplication of data. Different applications keep their own copies of the same facts, so the copies drift out of sync and you can’t tell which is correct.
3. Limited data sharing. Each application’s files are private, so cross-departmental access is hard.
4. Lengthy development times. Every new application designs its files from scratch.
5. Excessive program maintenance. All of the above compound — in file-processing shops, as much as 80% of the IS budget could go to maintaining existing programs rather than building new ones.

Worked example: program-data dependence in action

Suppose a customer Address field is widened from 30 to 40 characters. In file processing, the 30 is hardcoded in every program:

Billing program     → reads Address as CHAR(30)   ← must edit
Shipping program    → reads Address as CHAR(30)   ← must edit
Marketing program   → reads Address as CHAR(30)   ← must edit

The data described itself *through the code*, so a data change forces a code change everywhere — the very definition of program-data dependence.

The fix: the database approach and data independence

The database approach centralizes data and its descriptions. The cornerstone benefit is program-data independence: data descriptions (metadata) live in a central repository, *separated* from the programs. Applications reference the repository instead of hardcoding the layout, so the structure can evolve (within limits) without rewriting application code.

The approach brings ten interdependent advantages: program-data independence, planned (controlled) data redundancy, improved data consistency, improved data sharing, increased development productivity, enforcement of standards, improved data quality, improved data accessibility/responsiveness, reduced program maintenance, and improved decision support. Note “planned” redundancy — the database approach doesn’t forbid all duplication; it makes any redundancy *deliberate and managed* rather than accidental.

These are *potential* benefits, not guarantees: weak database administration or lack of management commitment can squander them. And the approach has real costs too — new specialized personnel, installation cost/complexity, conversion of legacy systems, the need for explicit backup/recovery, and organizational conflict over shared definitions.