Architecture for very long process (a persons life time)

I am looking at now to design systems that will store data that will be used over a very long time.

The type of systems are medical, follow a 开发者_Python百科person from when they are born to when they die, or insurance systems that follow a person from when they start working untill their insurance expires.

How would you do this? Both for storing records information and storing documents.

For example MS Word 2010 files might not be readable in 2050, or would they? Will Oracle or MS SQL server be around for much longer, or should we just store every thing in XML text files?

Haivnng worked on several long-term insurance systems, there's honestly not a great deal of thought given to whole-lifetime use. Typically systems are built to last for ten years or so^*, and whenever they "wear out" -- when they're now failing to provide for the current business needs, or when their hardware looks too expensive and obsolete to maintain -- the data is migrated to a new system.

Migrations can be fairly costly, but they're usually quite "doable"; you may only be moving documents from an elderly but still-loadable version of Word and shoving them into a new content management system, or moving databases from an AS/400 system to a new SQL Server system.

So, I'd say that what happens for the insurance systems, at least, is that you don't plan for the lifetime of a person, just the lifetime of a system, and take whatever hit you have to when moving to the next system along, gradually, decade by decade, moving the data to newer systems and currently-supported newer formats every time.

_{*Acutally, that lifetime isn't exactly true. Typically systems are allegedly designed to last for twenty years, at least by the people justifying the project costs. But then they normally only last for about ten years before being thrown out :)}

It's impossible to know what technology will be around in 10 years, so forget about predicting year 2050.

It is natural for software to be upgraded during it's lifetime, to be replaced with better alternatives, and formats for data storage to change.

Plain text is the most portable form of data storage in existence, so use it in whatever way you find appropriate. Don't use binary.

Use a database for large amounts of data, since this data can be exported into plain text and once again inserted into another database if, let's say, Oracle ceases to exist one day and you choose PostgreSQL which survived.

Data structure evolves. But there is always support to data structure for a verylong period of time, considering the Language C, it is still used in a lot of places but the usage has been narrow down to its speciality area (in the case of C its embedded systems).

In my opinion, even XML is outdated facebook and many popular website use JSON now. But I am sure XML will be in development for the next 30 years atleast.

Change is the only Constant.

Data migrations are always possible. And ideally migration of databases occur when there is a massive performance increase, which does not happen too often with in a span of 5-8 years.

Make sure you don't invent your own storage format, and avoid using any proprietary format, too.

No one knows what will be around in ten year's time, so you should at least make sure the format you use is well documented. So go for an established ISO or similar standard (this could be XML, or a conforming SQL database).