Situations Where DBMS is not necessary

It is also necessary to specify situations where it is not necessary to use a DBMS. If traditional file processing system is working well, and if it takes more money and time to design a database, it is better not to go for the DBMS. Moreover if only one person maintains the data and that person is not skilled in designing a database as well as not comfortable in using the DBMS then it is not advisable to go for DBMS.

DBMS is undesirable under following situations:

1. DBMS is undesirable if the application is simple, well-defined, and not expected to change.
2. Run time overheads are not feasible because of real-time requirements.
3. Multiple accesses to data are not required.

Well, it isn’t necessary in a lot of places, but I will assume you are talking about information storage and access.

Wherever you do not expect concurrent access to the data and do not need simple structured access to parts of the data. Example: application’s local settings (like an .INI file). The application is the only editor and consumer of this data and typically it would need the whole structure at once, so just load the XML or JSON from the disk file into the in-memory structure and you are good to go. Although even then some vendors would use a SQLite database (call it DBMS or not is a call I’m not making now) to be able to address particular settings with a SQL expression.

I’m sure there are other good examples.

Applications that don’t need all of the data at once and data that needs concurrent access from multiple consumers almost always means DBMS. It is a pretty broad range, but there are also many DBMS in different shapes and flavors.

Source: www.quora.com