Как “обновить” базу данных в реальном мире?
Моя компания имеет, разрабатывают веб-приложение с помощью php + mysql. Система может отобразить исходную цену продукта и сниженную цену пользователю. Если Вы не вошли в систему, Вы получаете исходную цену, если Вы вошли в систему, Вы получаете сниженную цену. Довольно легко понять.
Но моя компания хочет больше функций в системе, она хочет отобразить другую ценовую основу на другом пользователе. Например, пользователь A является золотым parnter, он может получить 50% от. Пользователь B является серебром parnter, только имейте 30% прочь. Но эта логика не, готовятся в исходной системе, таким образом, я должен добавить некоторый атрибут в базе данных, по крайней мере, пользовательский тип в этом примере. Есть ли любая рекомендация о том, как объединить текущую базу данных с моей новой версией базы данных. Кроме того, все данные должны хранитель, и сервер должен работы 24/7. (в остановке база данных)
Действительно ли возможно сделать так? Кроме того, кто-либо рекомендует для будущего maintaince совет? Thz u.
3 ответа
Вы использовали ORM для уровня доступа к данным? Я знаю, что Doctrine поставляется с API миграции, который позволяет переключаться между версиями вверх и вниз (на случай, если что-то пойдет не так с новой версией).
Если не принимать во внимание фреймворк или ORM, быстрый сценарий минимизирует замедление (или время простоя, если процесс слишком долгий).
На мой взгляд, я бы предпочел прерывание доступа к веб-сайту на 30 секунд с помощью информационной страницы, чем сокращение времени прерывания, но с видимыми ошибками или вообще без отображения. Если время перерыва имеет значение, лучше делать это ночью или при меньшей загруженности дорог.
Все это может быть выполнено в одном сценарии (или, по крайней мере, запущено одной командной строкой), при выполнении таких сценариев мы включаем в сценарий оболочки:
- перевод приложения в режим ожидания (временная статическая страница): вы можете использовать перенаправление .htaccess или все, что применимо к вашей среде приложения / сервера.
- svn udpate (или переключатель) для обновления исходного кода и ресурсов
- пустые кеши, очистка временных файлов и т. Д.
- перестройка сгенерированных классов (для Symfony)
- обновление структуры базы данных с помощью запросов ALTER / CREATE TABLE
- при необходимости перенесите данные из старой структуры в новую: в зависимости от того, что вы изменили в структуре, может потребоваться выборка данных перед изменением структуры БД или использование таблиц tmp.
- Если все прошло успешно, удалить временную страницу. Обновление выполнено
- , если что-то пошло не так, отобразить красное сообщение для оператора, чтобы он мог видеть, что произошло, попытаться исправить это, а затем вручную удалить ожидающую страницу.
Сценарий должен выполнять проверки на каждом этапе и останавливать первую ошибку, и он должен быть подробным (но кратким) о том, что он делает на всех этапах, чтобы вы могли быстрее исправить приложение, если что-то пойдет не так. Лучшим будет сценарий с возможностью восстановления (ошибка на шаге 2 - остановка процесса - ручное исправление - восстановление на шаге 3). Я никогда не тратил время на то, чтобы реализовать его таким образом.
If работает довольно хорошо, но такие сценарии должны быть тщательно протестированы в среде, максимально приближенной к производственной. Обычно мы разрабатываем такие сценарии локально и тестируем их на той же платформе, что и производственная среда (только разные пути и БД)
Если ожидающая страница не подходит, вы можете обойтись без нее, но вам нужно убедиться, что данные и пользователи целостность сеанса. Например, используйте LOCK для таблиц во время обновления / передачи данных и используйте эксклюзивные блокировки для измененных файлов (SVN, я думаю)
Могут быть и другие лучшие решения, но в основном это то, что я использую, и он выполняет свою работу за нас. Основным недостатком является то, что сценарий приходилось переписывать при каждом крупном выпуске, это побуждает меня искать другие варианты для этого, но какой ??? Я был бы рад, если бы у кого-то здесь была альтернатива получше и попроще.
Я бы порекомендовал написать инструмент для постепенного выполнения SQL-запросов к вашим базам данных. Очень похоже на миграции Rails.
В системе, над которой я сейчас работаю, у нас есть такой инструмент, написанный на python, мы называем наши скрипты как-то вроде 000000_somename.sql, где нули - это номер версии в нашей SCM (подрывной деятельности), а инструмент запускается как часть разработки / тестирования и, наконец, развертывание в продакшене.
Это дает возможность вернуться в прошлое с точки зрения изменений базы данных, так же, как и в коде (если вы используете инструмент контроля версий исходного кода).
http://dev.mysql.com/doc/refman/5.1/en/alter-table.html
Вот более конкретные примеры ALTER TABLE.
http://php.about.com/od/learnmysql/p/alter_table.htm
Вы можете добавить необходимые столбцы в свою таблицу с помощью ALTER TABLE, а затем установить тип пользователя для каждого пользователя с помощью UPDATE. Затем разверните новую версию своего приложения. который использует новый столбец.