Архитектура для очень длительного процесса (время жизни людей)

Question

Сейчас я смотрю на разработку систем, которые будут хранить данные, которые будут использоваться в течение очень долгого времени.

Тип системы - медицинский, следует за человеком с момента его рождения и до его смерти, или системы страхования, которые следуют за человеком с того момента, когда он начинает работать, до истечения срока действия страховки.

Как бы вы это сделали? Как для хранения информации записей, так и для хранения документов.

Например, файлы MS Word 2010 могут быть недоступны для чтения в 2050 году или нет? Будет ли сервер Oracle или MS SQL работать намного дольше, или мы должны просто хранить все в текстовых файлах XML?

Answer 1

Haivnng работал над несколькими системами долгосрочного страхования, и, честно говоря, не много внимания уделяется использованию на протяжении всей жизни. Обычно системы рассчитаны на десять лет или около того ^* и всякий раз, когда они «изнашиваются» - когда они не в состоянии удовлетворить текущие потребности бизнеса или когда их оборудование выглядит слишком дорогим и устаревший в обслуживании - данные переносятся в новую систему.

Миграции могут быть довольно дорогостоящими, но обычно они вполне выполнимы; вы можете перемещать документы только из устаревшей, но все еще загружаемой версии Word и помещать их в новую систему управления контентом или перемещать базы данных из системы AS / 400 в новую систему SQL Server.

Итак, я бы сказал, что, по крайней мере, для страховых систем происходит то, что вы не планируете жизнь человека, только жизнь системы, и берете все, что угодно Удачи вам придется, когда вы переходите к следующей системе, постепенно, десятилетие за десятилетием, каждый раз перемещая данные в более новые системы и поддерживаемые в настоящее время новые форматы.

_{* На самом деле это время жизни не совсем верно. Обычно системы предположительно рассчитаны на двадцать лет, по крайней мере, людьми, оправдывающими стоимость проекта. Но тогда они обычно длятся только около десяти лет, прежде чем их выбрасывают:)}

Answer 2

Невозможно знать, какие технологии появятся через 10 лет, поэтому забудьте о прогнозировании 2050 года.

Естественно, что программное обеспечение обновляется в течение его срока службы, заменяется лучшими альтернативами и форматами.для хранения данных.

Обычный текст - самая переносимая форма хранения данных, поэтому используйте ее любым удобным для вас способом.Не используйте двоичный файл.

Используйте базу данных для больших объемов данных, поскольку эти данные можно экспортировать в обычный текст и снова вставить в другую базу данных, если, скажем, Oracle однажды прекратит свое существование, и вывыберите PostgreSQL, который выжил.

Answer 3

Убедитесь, что вы не изобретаете свой собственный формат хранения, и избегайте также использования любого проприетарного формата.

Никто не знает, что будет через десять лет, поэтому вы должны по крайней мере убедиться, что используемый вами формат хорошо задокументирован.Поэтому перейдите к установленному ISO или аналогичному стандарту (это может быть XML или соответствующая база данных SQL).

Answer 4

Структура данных развивается.Но всегда существует поддержка структуры данных в течение очень длительного периода времени, учитывая язык C, он все еще используется во многих местах, но его использование было ограничено его специализацией (в случае C его встроенные системы),

На мой взгляд, даже XML устарел в Facebook, и многие популярные веб-сайты сейчас используют JSON.Но я уверен, что XML будет в разработке не менее 30 лет.

Change is the only Constant.

Перенос данных возможен всегда.И в идеале миграция баз данных происходит при значительном увеличении производительности, что не часто происходит в течение 5-8 лет.