Advantages and Limitations of a DBMS
A DBMS buys controlled redundancy, enforced integrity, sharing, security, recovery and independence. It charges for them in cost, complexity, hardware and the risk of putting everything in one place.
-
DBMS Fundamentals
- Data, Information and Databases
- What a DBMS Is and Why It Exists
- File System versus DBMS
- Advantages and Limitations of a DBMS
- Database Users and the Role of the DBA
- Three Level Architecture and Data Abstraction
- Logical and Physical Data Independence
- Schema, Instance and Metadata
- Database Applications and the Database System Environment
- Database Architecture
- Data Models
-
ER Model
- Entities, Entity Sets and Entity Types
- Types of Attributes in the ER Model
- Keys in the ER Model
- Relationships, Relationship Sets and Degree
- Cardinality and Participation Constraints
- Strong and Weak Entities
- Drawing and Reading ER Diagrams
- Extended ER: Generalisation, Specialisation and Aggregation
- Converting an ER Diagram into Relational Tables
- ER Design Projects
- Relational Model
- Relational Algebra
- Functional Dependencies
-
Normalisation
- Why Normalisation Exists: Anomalies and Redundancy
- First Normal Form
- Second Normal Form and Partial Dependency
- Third Normal Form and Transitive Dependency
- BCNF and BCNF Decomposition
- 4NF, 5NF, Multivalued and Join Dependencies
- Lossless Decomposition and Dependency Preservation
- Complete Worked Normalisation: Unnormalised to BCNF
- Denormalisation and When to Use It
Concept
Most notes list only advantages, which is why the limitations question catches people out. A DBMS is a trade: real benefits bought with real costs. Knowing both is what lets you argue for or against one in a design discussion.
Advantages
| Advantage | What it means in practice |
|---|---|
| Controlled redundancy | One fact is stored once and referenced elsewhere, so it cannot drift out of step with itself. |
| Consistency | Constraints reject the update that would break a rule, instead of trusting every programmer to remember it. |
| Data sharing | Many users and many applications work on the same current data at the same time. |
| Enforced integrity | Rules are declared once in the schema and applied to every access path, including manual ones. |
| Security | Privileges by user, role, table, column and sometimes row, instead of all or nothing file permissions. |
| Backup and recovery | Logging and checkpoints restore a consistent state after a crash without hand written repair. |
| Atomicity | Multi step operations complete fully or not at all. |
| Data independence | Storage and structure can change without rewriting the applications above. |
| Ad hoc querying | A new question is a query, not a development project. |
| Standards enforcement | Naming, formats and types are applied centrally across all data. |
| Reduced development time | Applications inherit storage, concurrency, integrity and recovery instead of building them. |
| Concurrent access | Correct results under many simultaneous users, guaranteed by the system. |
Limitations
| Limitation | Why it bites |
|---|---|
| Cost | Licences, or the staff time to run an open source system properly. |
| Hardware demand | Memory for buffers and caches, fast disks, and headroom for peak concurrency. |
| Complexity | A large body of features. Misconfiguration silently removes the benefits you bought it for. |
| Specialist skill | Needs a DBA, or someone doing that job under another title. |
| Performance overhead | Parsing, planning, locking and logging cost time. For one simple sequential read, a file is faster. |
| Single point of failure | Centralising data centralises the outage. Everything stops together unless you design for it. |
| Migration cost | Moving from one product to another is slow once proprietary features are used. |
| Overkill for small problems | A hundred rows read by one program does not need a database. |
| Concentrated impact of damage | One bad update or one leaked credential can affect every application at once. |
Example
A three person shop tracking 400 products
DBMS correct data, real queries, backups, but a
server to run, patch, secure and back up
Spreadsheet free, instant, familiar, but no concurrency,
no constraints, no audit, and one bad sort
silently misaligns every column
Right answer: still a database, because the failure mode of
the spreadsheet is SILENT and the failure mode of the
database is LOUD. Loud failures get fixed.Where the trade genuinely goes the other way
- Configuration for a single application — a file is simpler and versionable.
- Very high volume append only telemetry read once and discarded.
- Large media files, where the database stores the metadata and the file system stores the bytes.
- A one off analysis on a dataset that will never be updated.
Common mistakes
- Listing advantages only. The limitations half is worth marks and is usually where the follow up question goes.
- Saying a DBMS is always faster. For a single sequential scan of one file it is not. It is faster for selective access, and correct under concurrency, which usually matters more.
- Ignoring the single point of failure. Centralisation is the main advantage and the main risk in the same sentence.
- Assuming security is automatic. A DBMS provides the mechanism. A default password removes the benefit entirely.
Exam and interview questions
- List eight advantages of a DBMS with one line of explanation each.
- List five limitations and explain which one worries you most in a small organisation.
- Why is centralisation both an advantage and a disadvantage?
- Give two situations where you would advise against a DBMS.
- Explain why a DBMS can be slower than a file for one particular access pattern.
Practice
- Choose an application you use daily. Write three advantages a DBMS gives it and two costs its owners must be paying.
- Argue in five sentences against using a DBMS for a single user note taking tool.
- Explain how the single point of failure risk is reduced without giving up centralisation.
Conclusion
A DBMS trades cost, complexity and centralised risk for correctness, sharing, security and recoverability. For anything with several users or several applications, that trade is almost always worth making — but say almost, and be ready to name the exceptions.