LINUX.ORG.RU

Что делать с документами на старых базах данных?

 , ,


0

2

Здравствуйте!

У меня задача разработать на одном предприятии новую версию(вариант) ПО, которая является одной маленькой частью большой системы. А на этом предприятии стоит три версии этих систем, поэтому на данный момент существует три разных сервера баз данных MSSQL Server 2000, mSSQL Server 2008 и Firebird. В этих базах данных хранятся документы клиентов, застрахованных лиц, их средства и разного рода документы, связанные с разными финансовыми операциями. В идеале данные должны быть мигрированы, но так как я пока один, у меня нет на это времени. Но нужные данные я должен как-то собрать. и cтоит вопрос что делать со старыми документами, в которых хранится информация о средствах.

Пока вижу два варианта: 1. Просто сохранить как остаток в новой базе, некоторые не советуют этого делать. 2. Использовать старую базу данных вместе с новой, и соединяться, когда потребуется, но СУБД старая, и у меня нет уверенности, что это нормально.

Помогите, пожалуйста! Хотелось бы узнать, что думают опытные разработчики.

Спасибо!

Ответ на: комментарий от deep-purple

если и сделаю миграцию, я займусь ей в последнюю очередь, но боюсь, все равно не успею

Есть ли какой-нибудь способ надежно сохранить остатки средств в новой базе, чтобы никто не мог их изменить?

Rovshik ()

Хотелось бы узнать, что думают опытные разработчики

Ты как бы не по адресу обращаешься. Огласи варианты заказчику, путь он и думает, что ему лучше.

В идеале данные должны быть мигрированы, но так как я пока один, у меня нет на это времени

А в чём проблема, там дохрелион таблиц? На первый взгляд сдампить SQL и всосать на новый сервер выглядит как задача на пару дней максимум.

no-such-file ★★★★★ ()

У меня была похожая ситуация. Пришли к варианту 3 - постепенно (при первой работе с объектом в новой системе) делался запрос данных в старую, а оператор сверялся с данными и, при необходимости, вносил корректировки (т.к. новая система стала более детализированная в вопросах работы со средствами).

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

gruy ★★★★ ()

должны быть мигрированы, но так как я пока один, у меня нет на это времени

Ну т.е. время отлаживаться на 3-х (!) старых базах (с разными ведь схемами?) есть, а на миграцию нету?

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

pru-mike ★★ ()

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

dicos ()
Ответ на: комментарий от Rovshik

Откладывать миграцию важных данных на последний этап это граблеопасный подход. Данные это самое ценное что есть у пользователя ИС. Договаривайся с заказчиком на перенос времени запуска

cobold ★★★ ()
Ответ на: комментарий от cobold

У меня задача разработать на одном предприятии новую версию(вариант) ПО, которая является одной маленькой частью большой системы

То есть по итогу будет 4 версии ПО на предприятии.

А миграция = 1-tool-to-rule-them-all

И года выяснится что у «новой программы» есть фатальный недостаток(а это выяснится) будет ТС бегать с горящей жопой, или просто скроется

А потому лучшее что можно сделать - разделение ответственности ИС: и все что новая ИС не пишет, пусть собирает из трех других ИС по ночам

Тем более ТС говорит что он один, а значит там не будет ни QA, ни прочих третьих глаз

anonymous ()
Ответ на: комментарий от anonymous

да, о таком сценарии я тоже подумал, но решил, что тс, как человек на месте, лучше знает местные реалии разработки и эксплуатации и какую задачу ему ставил заказчик. Я прочитал из оп поста, что задача заменить(возможно поэтапно) 3 имеющихся приложения одним новым, возможно ошибся

cobold ★★★ ()

Разбирайся, насколько отличается структура данных в этих 3 старых базах от твоей текущей. То, что используются разные СУБД — не очень большая проблема, преобразовать из одного формата в другой не должно быть особенно сложно (тем более, что наверняка есть импорт/экспорт в какой-нибудь CSV), но только если структура данных не сильно отличается. Плюс, как уже сказали, может быть проблема с ключами. Она тоже решается. Например, добавляешь поле oldId, куда помещаешь ключ из старой базы, а основной id будет уже автоинкрементальным в рамках твоей новой базы. Но если структура отличается сильно, при миграции потребуются какие-то нетривиальные преобразования, тогда да, это может стать проблемой, тогда нужно думать в сторону какой-то интеграции со старой базой, которая останется как есть

Dobriy_i_Prostoy ()