Serialization to Disk inplace of creating a simple database... Is there a pattern or industry name for this approach?

I am leading a development team of 5 or so developers and we have a need to persist a small amount of data.

I am thinking we do not need to employ a full DB engine and instead we can simply serialize our data to disk. We would serialize our collections of object to and from disk as needed at runtime instead of to a DB where we have to map tables to and from the objects. At most we have about 20 objects and I cannot imagine our object count would ever extend into the thousands..

Part of the team wants to go the data base route as it is understood. The other part thinks serialization is OK.

My question is not how to do it.. but is there a keyword, or a name or something that identifies the activity of using serialization as the DB for the application as apposed to SQL or Oracle? What is a keyword so I can look up white papers or other information and can find documentation specific to that approach?

**** additional info *****

There will be concurrency issues, but those can be mitigated via a controlled interface that would provide the synchronized access to the serialized data files.

Transactions, although not needed for this application, would be managed (in practice if needed) by a similar pattern as transactions employ. Start transaction would make a back up of the data files on disk, and commit would return successful if the data was written to disk without issue.

At most we have 20 base entities that need to be persisted and the number of objects to be stored would never be into the thousands. Nor is there a need for rapid and repeated access to the data, just occasional reads and writes (at most a couple times every several minutes).

I have both the concurrency and transactional needs covered if using DB or Serialization to disk. Since we do not need 'views, stored procedures, indexes, support for SQL etc... I am at a loss as to why we need a DB.

There is a data access layer (repository) and the application is factored quite cleanly. The serialization could easily be replaced with a DB or the other way around.

What I am really after is a contrast and comparison between the two approaches. I am after any real world documented user studies between the two approaches. I am just trying to find a hook into those topics so I can research the pros and 开发者_JS百科cons more.

---

The questions you need to answer when deciding between serialize to disk or database are:

• Do you need transactions. If Yes: Database.
• Do you need several users writing to same object: If Yes Database.

I have done the serialize to disk for single user systems, worked fine.

You should architect your system with a data access layer, the rest of the system will not know how the data is being stored. You can then change it later if you need to.

Keywords to search for would be serialization / Streaming to file.

---

I have one proposal. Store you object into the local DB like SQLite. It will be both DB and kind of Disk serialization.