Choosing Files vs a DBMS Under Real-Time, Multi-User, and Complex-Relationship Workloads

When deciding between file-based storage and a DBMS (Database Management System), the question is not “which is always better,” but which architecture better satisfies the constraints: real-time latency, concurrency (multiple users), and ability to manage relationships/integrity.

In most database curricula, the correct option for the provided multiple-choice question is (iv) All of the above—because each listed condition corresponds to a scenario where DBMS features (concurrency control, transactions, integrity constraints, and relationship modeling) become important. However, note the subtle framing: some real-time systems may prefer specialized file/in-memory approaches, but within the standard “files vs DBMS” conceptual comparison, the intended takeaway is that these requirements push you toward using a DBMS. For example, a DBMS is described as providing capabilities for concurrent access and object/relationship management that file systems do not handle directly. It is also explicitly noted that real-time applications requiring complex data management can be harder to combine with file-based data management. 3

Key keyword concepts used below: transactions, concurrency control, referential integrity, and querying complex joins.

Interpreting the Multiple-Choice Statement

The statement asks:

“It is better to use files than a DBMS when there are
(i) stringent real-time requirements
(ii) multiple users wish to access the data
(iii) complex relationships among data
(iv) All of the above”

From the standard DBMS-vs-file-system perspective:

• For complex relationships, DBMS is designed to manage and enforce relationships (file systems lack object/relationship concepts).
• For multiple users, DBMS provides efficient concurrent access mechanisms (file systems rely on ad-hoc locking/pooling and can yield anomalies; DBMS manages concurrency more directly). 2
• For real-time requirements, the discussion of file-based approaches indicates that real-time applications needing complex memory/data management can be difficult to combine with file-based data management, motivating a more capable managed system approach.

Therefore, the intended correct answer in typical course material is (iv) All of the above (i.e., the conditions point toward preferring DBMS features rather than raw files). 2

Academic note: In some specialized embedded/ultra-low-latency contexts, specific file-like layouts (or in-memory stores with careful engineering) can be faster than general DBMS stacks. But the exam framing here is the classic “DBMS vs files” conceptual decision.

Condition (i): Stringent Real-Time Requirements

What “real-time” typically implies

Real-time requirements constrain response time predictability and the ability to maintain correctness while processing data under tight deadlines.

From the file-vs-DBMS comparison literature:

• Real-time applications that need complex memory and data management may find it hard to combine in-memory management with file-based data management.
• This suggests that when real-time workloads also require complex data handling, DBMS-style managed approaches are favored over simplistic file handling.

Key keyword="A deadline constraint on how quickly the system must respond to events." Key keyword="Predictable timing: response time variation must be bounded." Key keyword="Keeping active data in RAM for faster access." Key keyword="Operations where the system enforces correctness rules (e.g., transactions)."

Condition (ii): Multiple Users Wish to Access the Data

Why concurrency pushes toward DBMS

When multiple users/applications read and write shared data concurrently, you must handle:

• lost updates,
• inconsistent reads,
• write-write conflicts.

A standard DBMS advantage is concurrent access and transaction management compared to a normal file system.
Additionally, DBMS-vs-file-system discussions note that file-based sharing forces the application to manage sharing logic because file systems don’t notify waiting applications when locks are released; DBMS manages concurrent access efficiently.

Key keyword="Mechanisms that coordinate simultaneous operations to preserve correctness." Key keyword="A unit of work that must be executed reliably with all-or-nothing effects." Key keyword="Atomicity, Consistency, Isolation, Durability; properties targeted by transaction systems." Key keyword="A concurrency anomaly where one update overwrites another without detection."

Condition (iii): Complex Relationships Among Data

Why relationships push toward DBMS

If your data includes multiple entity types with relationships, you typically need:

• structured representation,
• relationship-aware querying (joins),
• integrity rules to prevent orphaned/inconsistent references.

DBMS comparisons explicitly state that file systems have no object concept and thus lack ability to manage object relationships directly, while DBMS is designed to provide and manage object relationships.
For relational integrity, referential integrity is commonly enforced using constructs like foreign key constraints (with cascading options in many systems).

Key keyword="Constraint ensuring referenced rows exist, preventing orphaned records." Key keyword="A column/group of columns referencing a primary key in another table." Key keyword="A query operation combining related rows from multiple relations." Key keyword="Structured definition of tables/fields/constraints."