Две базы молочного комбината, учёт производства на IBM DB2 и лабораторная система на Sybase ASE, перенесены в одну базу PostgreSQL вместе с хранимыми процедурами. Переезд провёл Евгений Росляков. С 2016 года он делает сайты и работает с базами данных, а с комбинатом общался удалённо, из Москвы. Он самозанятый, подписывает договор и выдаёт юрлицам закрывающие документы.
Комбинат принимает молоко, ведёт партии, рецептуры и лабораторный контроль. Учёт производства стоял на DB2: его ставили вместе со старой системой ещё в 2000-х. Лабораторные анализы жили отдельно, на Sybase.
Поддержки и лицензий на обе СУБД нет, купить или продлить их сейчас нельзя. Программистов, знающих обе системы, у комбината нет, а единственный человек, помнивший устройство баз, ушёл на пенсию. Любая правка превращалась в риск.
Связь между партией молока и анализом шла вручную: технолог открывал одну программу, выписывал номер партии и искал его в другой. Нужно было перенести всё на открытую СУБД без простоя производства и без потери истории.
Выбрали PostgreSQL: она бесплатная, живая, документации и специалистов по ней достаточно. В техническом задании комбината её называли «PostgresSQL» — с опечаткой, которая так и прижилась. Я оставил это написание там, где оно уже стояло в документах, чтобы никого не путать, а в самой базе и в коде всё называется как положено.
Сначала перенёс схемы. Типы данных в DB2 и Sybase отличаются от PostgreSQL, поэтому пришлось сопоставить даты и время, десятичные числа, символьные поля. С массой и деньгами особая аккуратность: десятичные значения хранятся как numeric, чтобы граммы не терялись на округлении.
Основное время заняло программирование PostgreSQL: процедуры. В DB2 они написаны на SQL PL, в Sybase на Transact-SQL, и всё переписано на PL/pgSQL: функции, триггеры, транзакции. Строчка в строчку переводить почти нечего, поэтому я сначала выяснял, что процедура делает для технолога, и писал заново. Каждую функцию гоняли на тестовых данных вместе с сотрудниками.
Партии молока и лабораторные анализы теперь лежат в одной базе и связаны ключом. Технолог видит результат анализа прямо в карточке партии.
Данные за десять лет переносил в несколько заходов. После каждого сверял количество записей и контрольные суммы по таблицам, потом сравнивал отчёты за выбранные месяцы со старой системой. Расхождения разбирали вручную.
Месяц обе системы работали параллельно: смена вносила данные в новую, а я сверял итоги со старой. Потом старые серверы выключили. Индексы и настройки подобрал под нагрузку смен, и утром, когда идёт приёмка, база отвечает без задержек.
Комбинат работает на одной базе вместо двух старых. Партия и её анализы видны вместе, и технологу не нужно переписывать номера между программами.
Зависимости от СУБД, которые никто не поддерживает, больше нет. Новый отчёт или поле может добавить любой программист, знающий PostgreSQL, а не человек, помнящий DB2 или Sybase. Система перестала быть чёрным ящиком, и для комбината это главное.
Месяц параллельной работы дал уверенность. Сотрудники сами убедились, что цифры совпадают, и переход прошёл без остановки смен.
Есть ограничения. Часть мелких отчётов, которые давно никто не открывал, я не переносил, а сохранил в архиве: если понадобятся, их придётся восстановить. Клиентская часть осталась прежней и теперь подключается к PostgreSQL через драйвер, поэтому в программе всё выглядит как раньше. Так сделано намеренно, чтобы никого не переучивать, но когда-нибудь интерфейс тоже стоит обновить.
Следующим шагом планируем автоматические резервные копии с проверкой восстановления и регламент для местных ИТ-специалистов.
Если у вас тоже доживает СУБД без поддержки, свяжитесь со мной на freelance.ru: что стоит, с какого года и сколько в ней процедур. По этим трём ответам прикину объём переезда.
