I will refer predominantly to Relational DBMS. In a file system, data is contained in a flattened structure that is often a variable length structure. For example, a shipment received could contain the shipping header (with [Ill abbreviate but you should use proper names] SNO, SNAME, SADDRESS, SHIPPER NO, SHIPPER NAME, etc.) and shipping details (Items shipped, item name, item standard price, shipped quantity, date shipped, date received, who received, etc., and total cost of the shipment. All this might be contained within a single hybrid (variable length) structure. This structure must have integrity with other data within the organization. For example, the Shipper No and Name must be a real shipper, that exists. File systems do not ensure this. IN a file system, the application must ensure that there is integrity between Shipment, Supplier and your company. DBMS ensure integrity. Most DBMSs would split this example into several structures: Shipment, Shipper, Shipment Item, Supplier No, etc., but these structures would be interrelated. -- by the designer who set up the database but once set up would be enforced by the DBMS itself. Besides, DBMSs keep logs to allow you to recover to a particular point, have utilities for fast loading, have a catalog that keeps statistics, has a specific language for access. In general, however, file systems can be faster because they have less overhead. I would also say a database is easier to maintain. There are DBMS statements that allow you to define the database, access it, etc. You can also index a database. For example, we could create a composite index that contained Shipment No, Shipper Name, Item No to allow us to retrieve from all three faster. In file systems, each file is separate. Those are some of the pros and cons of DBMS vs. file systems.
Login to rate this answer.