These differences have consequences for very nearly every aspect of database management, from concurrency control to application interfaces. It is likewise important to address three inquiries that have regularly got some information about MMDBs. Is it reasonable to accept that the whole database fits in main memory? Yes, for a few applications. In a few cases, the database is of a constrained size or is developing at a slower rate than memory limits are developing. For instance, the database size may be corresponding to the number of workers or clients in an organization, and regardless how fruitful the organization is, it is sensible to expect that memory can hold a couple of hundred or thousand bytes for every worker or client. In some real time applications, the information must be memory occupant to meet the ongoing imperatives, so the database will essentially be less than the measure of accessible memory. Case of such real-time applications incorporates telecommunications, radar tracking, and security trading.
What is the difference between a MMDB and a DRDB with a very large cache? On the off chance that the cache of a DRDB is vast enough, duplicates of the information will dwell in memory at all times. In spite of the fact that such a system will perform well, it is not taking the full benefits of the memory. Case in point, the index structures will be intended for disk access, despite the fact that the data are in memory. Likewise, applications may need to get access to data through a buffer manager, as though an information were on the disk. For instance, each time a requisition wishes to access to a given tuple, its disk address will must be computed, and after that the buffer manager will be invoked to check if the relating block is in memory. When the block is found, the tuple will be replicated into an application tuple, buffer, where it is actually analyzed. Plainly, if the record will dependably be in memory, it is more proficient to allude to it by its memory address.
