Лучшие методологии контроля изменений базы данных
Обратите внимание, что вы можете сложить case совпадений, которые делают одно и то же:
switch ($today) {
case 'Mon':
case 'Tue':
case 'Wed':
// code here
break;
}
Но вам лучше просто создать небольшой массив, содержащий значения, которые вам нужны для дней, а затем посмотреть до текущего значения, используя имя дня в качестве индекса массива:
$leadtimes = [
'Mon' => [1, 2], // first value is for before 16:00, second is for after
'Tue' => [1, 2],
'Wed' => [1, 2],
'Thu' => [1, 4],
'Fri' => [4, 5],
'Sat' => [4, 4],
'Sun' => [3, 3],
];
Затем код для расчета времени выполнения заказа - это всего одна строка:
$leadtime = $leadtimes[date('D')][date('H') < 16 ? 0 : 1];
Затем подключите его к вашему выводим как в предыдущем случае:
echo
"<p>For Delivery on <strong> " .
date('D jS', strtotime("$Date + $leadtime days")) .
"</strong><p>";
Теперь, когда вы хотите изменить время выполнения, код для редактирования отсутствует, просто отрегулируйте значение в массиве.
И так как я давно занимался гольф-кодом, вот все это в одной строке:
echo date('D jS',strtotime('+'.['Mon'=>[1,2],'Tue'=>[1,2],'Wed'=>[1,2],'Thu'=>[1,4],'Fri'=>[4,5],'Sat'=>[4,4],'Sun'=>[3,3]][date('D')][date('H')<16].'day'));
5 ответов
Самым легким путем я видел обошедшийся без, помощь внешнего инструмента состоит в том, чтобы создать "патч схемы", если Вы будете. Патч схемы является просто простым t-sql сценарием. Патчу схемы дают номер версии в рамках сценария, и это число хранится в таблице в базе данных для получения изменений.
Любые новые изменения в базе данных включают создание нового патча схемы, который можно затем выполнить в последовательности, которая затем обнаружила бы, какая версия база данных в настоящее время включена и выполняет все промежуточные патчи схемы. Впоследствии таблица версии схемы обновляется любой датой/временем, которую патч выполнялся для хранения для следующего запуска.
Хорошую книгу, которая сообщает подробности как это, называют, Осуществляя рефакторинг Базы данных.
Если Вы хотите использовать внешний инструмент, можно посмотреть на проект Миграций Ruby или подобный инструмент в C# под названием Migrator.NET. Эти инструменты работают путем создания c# классов классов/рубина с "Вперед" и "Обратная" миграция. Эти инструменты более многофункциональны, потому что они знают, как продвинуться, а также назад в патчах схемы. Как Вы заявили однако, Вы не интересуетесь внешним инструментом, но я думал, что добавлю это для других читателей так или иначе.
Мне скорее понравился этот ряд: http://odetocode.com/Blogs/scott/archive/2008/02/03/11746.aspx
В моем случае у меня есть сценарий, генерируют каждый раз, когда я изменяю базу данных, я назвал сценарий как 00001.sql, n.sql, и у меня есть таблица с de количеством последнего сценария, который я имею, выполняются. Можно также видеть Документацию Базы данных
То, что я делаю:
- Все команды DDL, требуемые воссоздать схему (и хранимые процедуры и индексы, и т.д.), находятся в сценарии.
- Чтобы быть уверенным, сценарий в порядке, он время от времени тестируется (создайте базу данных, запустите скрипт и восстановите резервное копирование и проверьте работы базы данных хорошо).
- Для контроля изменений сценарий сохранен в Системе управления версиями (я обычно использую Подверсию).
Прием - то, что, если база данных не может быть снижена для воссоздания с, скажем, добавленным столбцом, у меня есть два изменения для создания, ALTER TABLE + модификация в сценарии. Немного больше работы, но, в долгосрочной перспективе, это побеждает.
пока Вы добавляете столбцы/таблицы к своей базе данных, это будет легкая задача путем сценариев этих изменений заранее в sql-файлах. Вы просто выполняете их. возможно, у Вас есть некоторый порядок выполнить их.
хорошее решение состояло бы в том, чтобы сделать один файл на таблицу, так, чтобы все изменения, принадлежащие этой таблице, были видимы тому, кто бы ни работает над таблицей (как работа над классом). то же допустимо для хранимых процедур или представлений.
более трудная задача (и поэтому возможно, инструменты были бы хороши), должен отступить. пока Вы просто добавили таблицы/столбцы, возможно, это не будет большой проблемой. но если Вы отбросили столбцы на обновлении, и теперь необходимо отменить обновление, данные не там больше. необходимо будет получить эти данные из резервного копирования. но имейте в виду, если у Вас есть более затем несколько таблиц, это могло бы быть большой задачей, и в нормальном случае необходимо отменить обновление очень быстро!
если Вы могли бы просто восстановить резервное копирование, то его штраф в этот момент. но, если Вы обновляете в понедельник, Ваши клиенты работают до среды и затем они видят, что некоторые данные отсутствуют (который Вы просто выпали из таблицы), затем, Вы не могли только восстановить старую базу данных.
у меня есть основанный на модели подход в моем уме (извините, не реализованный в данный момент), в котором "смоделированы" изменения схемы (например, на xml), и во время обновления процессор (например, c# программа) создает весь необходимый "sql" и например, перемещает данные в "dropDatabase". данные могут находиться там, и если по некоторым причинам я должен восстановить некоторые отброшенные данные, я могу просто сделать это с процессором. я обдумываю некоторое время (годы), этот подход не так плох, потому что иначе разработчики не касаются "старых" таблиц, потому что они больше не знают, если таблица или столбец действительно необходимы. с этим подходом Вы не рискуете также партией при отбрасывании чего-то!