О системах планирования ресурсов предприятия Scala, iScala
“ Один из моих клиентов дал мне доступ только в тестовое окружение, где актуальность данных соответствовала рабочим данным 2-3 месячной давности. А общение с сотрудниками велось на основе примеров конкретных заказов, они не хотели заходить в тестовое окружение и вколачивать примеры из 80-150 строк. В этой ситуации логичной кажется просьба к ИТ сотрудникам обновить данные в тестовом окружении: берётся резервная копия БД с рабочего сервера и восстанавливается на тестовом сервере. И всё нажитое непосильным трудом нужно восстанавливать "по новой" :)
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Наши услуги
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  Базы данных и программирование  »»»  Обмен опытом: как переносить данные из рабочего окружения в тестовое

Обмен опытом: как переносить данные из рабочего окружения в тестовое

14.07.2023 Автор Алексей Васильев

Обычно мы разрабатываем отчёты и процедуры прямо на рабочем сервере, хотя это не самый правильный вариант. Помню как в начале обретения опыта по работе с SQL Server’ом я чуть не «положил» сервер, случайно запустив бесконечный цикл 🙂

Наиболее продвинутые компании, которые могут себе это позволить, обычно создают 3 отдельных окружения: Production (которое то ли в шутку, то ли по незнанию, иногда переводят как «Продуктовое»), т.е. рабочее, Development — окружение для разработки нового и Test — тестовое окружение. Я встречал даже PreProduction, ну, не знаю, это, на мой взгляд уже перебор, впрочем я всегда как в анекдоте про неопытного и опытного консультантов говорю: «раз так сделано, значит какой-то смысл в этом был, значит так кому-то было надо».

Нейросеть Кандинский на мой запрос про эти 3 сервера (окружения) выдала вот такую картинку:

Нейросеть Кандинский на мой запрос про эти 3 сервера выдала вот такую картинку

Но если серьёзно, как обычно происходит процесс обновления данных?

Если Вы работаете на рабочем сервере в той же базе данных, где хранит данные ваша система, то тут и вопрос не возникает. Они сразу актуальные, если мы говорим просто об их чтении (об отчётах). Если же ваша процедура что-то с этими данными делает и куда-то результат этих действий сохраняет, то обычно для разработки и тестирования таких процедур используют тестовую компанию. В Скале — обычно это отдельные таблицы внутри той же самой базы данных, так что вопрос также фактически не возникает (с небольшими нюансами). Иногда в Скале для каждой компании создаётся отдельная база данных и тут уже могут возникать вопросы с доступом. Аналогично, если существуют 3 отдельных окружения. Так, например, у одного из моих клиентов мне был предоставлен доступ только в тестовое окружение, где актуальность данных оставляла желать лучшего, данные примерно соответствовали рабочим данным 2-3 месячной давности. В то же время общение с сотрудниками велось на основе примеров конкретных заказов, разумеется, они не хотели заходить в тестовое окружение и вколачивать примеры из 80-150 строк. В этой ситуации логичной кажется просьба к ИТ сотрудникам клиента обновить данные в тестовом окружении. Как обычно это делается? Берётся резервная копия БД с рабочего сервера (или рабочей компании в Скале, если для каждой компании создаётся своя собственная БД) и восстанавливается на тестовом сервере (или в тестовой БД). И всё нажитое непосильным трудом нужно восстанавливать «по новой». Самое главное при этом, чтобы обновление произошло не в тот момент, когда вы вносите какие-то изменения в свои процедуры и ещё не успели сохранить их текст 🙂

Опытные люди при этом поступают иначе: они все хранимые процедуры или представления для отчётов или каких-то процедур преобразования данных размещают в отдельной специально для этого созданной базе данных. В этом случае при обновлении данных (восстановлении БД с данными системы из резервной копии с рабочего сервера или рабочей компании) ничего делать не требуется, все ваши наработки остаются нетронутыми. Я уже рассказал об этом (подсмотренным у клиента) подходе некоторым своим коллегам, но считаю, что нужно поделиться и с вами 🙂

Рубрика: Базы данных и программирование Метки: бэкап, структура БД, хранимая процедура
VK Telegram Про канал в WhatsApp

Copyright © 2025 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх