Вы помещаете свою базу данных статические данные в управление исходным кодом? Как?
Украденный отсюда: http://joakimandersson.se/archives/2006/10/05/test-your-rails-helpers/
require File.dirname(__FILE__) + ‘/../test_helper’
require ‘user_helper’
class UserHelperTest < Test::Unit::TestCase
include UserHelper
def test_a_user_helper_method_here
end
end
[Украденный от Матового Правила штукатура, кто также записал в этом потоке.] Можно сделать то же в RSpec как:
require File.dirname(__FILE__) + '/../spec_helper'
describe FoosHelper do
it "should do something" do
helper.some_helper_method.should == @something
end
end
9 ответов
Если вы изменяете статические данные (добавляете новый элемент в таблицу который используется для создания раскрывающегося списка), тогда вставка должна быть в системе контроля версий и развернута вместе с остальной частью кода. Это особенно верно, если вставка необходима для работы остальной части кода. В противном случае об этом шаге можно забыть, когда код будет развернут, и не произойдет ничего приятного.
Если статические данные поступают из другого источника (например, импорт текущих кодов аэропортов в США), вам может просто потребоваться запустить уже задокументированный процесс импорта. Сам процесс импорта должен находиться в системе контроля версий (мы делаем это со всеми нашими пакетами SSIS), но данные не обязательно должны быть.
Для первых двух шагов вы можете рассмотреть возможность использования промежуточного формата (например, XML) для данных, а затем использования собственного инструмента или чего-то вроде CodeSmith для генерации SQL, а также возможных исходных файлов. , если (например) у вас есть таблицы поиска, которые относятся к перечислениям, используемым в коде, - это помогает обеспечить согласованность.
Это имеет еще одно преимущество, заключающееся в том, что при изменении схемы во многих случаях вам не нужно повторно создавать все ваши INSERT заявления - вы просто меняете инструмент.
Я столкнулся с этим при разработке систем CMS.
Я добавил статические данные (то, что упоминается в коде) в сценарии создания базы данных, а затем отдельный сценарий для добавления любых «данных инициализации» (таких как страны, начальная совокупность продуктов и т. Д.).
Мне очень нравится ваше различение трех типов данных.
Я согласен с третьим .
В нашем приложении мы стараемся не вводить база данных первая , потому что она дублируется (как и должно быть в коде, база данных дублируется). Дополнительным преимуществом является то, что нам не требуется соединение или запрос для получения доступа к этому значению из кода, поэтому это ускоряет работу.
Если есть дополнительная информация, которую мы хотели бы иметь в базе данных, например, если она может быть измененным для каждого сайта клиента, мы разделяем их. Другие таблицы все еще могут ссылаться на эти данные (либо по индексу ex: 0, 1, 2, 3 или по коду ex: EMPTY, SIMPLE, DOUBLE, ALL).
В течение секунды скрипты должны находиться в системе контроля версий.
Во-первых, я никогда не использовал Visual Studio Database Edition. Вы благословлены (или прокляты) любыми инструментами, которые дает вам эта утилита. Надеюсь, это включает большую гибкость.
Я не знаю, могу ли я сделать такую большую разницу между вашими статическими данными типа 1 и типа 2. Оба являются наборами данных, которые определены один раз и никогда не обновляются, за исключением последующих выпусков и обновлений, верно? В этом случае основное различие заключается в том, как и почему данные остаются такими, какие они есть, а не столько в том, как они хранятся или инициализируются. (Если данные не зависят от среды, как в «A» для разработки, «B» для производства. Это будут данные «типа 4», и я с радостью проигнорирую их в этом посте, потому что я решил это с помощью SQLCMD переменные, и они вызывают у меня головную боль.)
Во-первых, Я бы сделал сценарий для создания всех таблиц в базе данных - желательно только один сценарий, в противном случае у вас может быть МНОГО сценариев (и поиск и замена, когда переименование столбцов становится очень неудобным). Затем я бы написал сценарий для заполнения статических данных в этих таблицах. Этот сценарий можно добавить в конец сценария таблицы или сделать его собственным сценарием, или даже сделать один сценарий для каждой таблицы, что является хорошей идеей, если у вас есть сотни или тысячи строк для загрузки. (Некоторые люди создают файл csv, а затем вводят в него BULK INSERT, но я бы избегал этого, потому что он просто дает вам два файла и сложный процесс [настройка сопоставления дисков при развертывании] для управления.)
Ключевой момент нужно помнить, что данные (хранящиеся в базах данных) могут и будут меняться со временем. Редко (если вообще! ) сможете ли вы удалить свою производственную базу данных и заменить ее свежей, блестящей, новой, лишенной всех этих бесполезных данных за прошлые бесчисленные годы. Базы данных - это все об изменениях с течением времени, и именно здесь скрипты становятся самостоятельными. Вы начинаете со сценариев для создания базы данных, а затем со временем добавляете сценарии, которые изменяют базу данных по мере появления изменений - и это также относится к вашим статическим данным (любого типа).
(В конечном итоге, моя методология аналогичен бухгалтерскому учету: у вас есть учетные записи, и по мере внесения изменений вы корректируете учетные записи с помощью записей журнала. Если вы обнаружите, что допустили ошибку, вы никогда не вернетесь и не измените свои записи, вы просто сделаете последующие записи, чтобы отменить и исправить их . Это всего лишь аналогия, но логика верна.)
новый, лишенный всех этих бесполезных данных за прошлые бесчисленные годы. Базы данных - это все об изменениях с течением времени, и именно здесь сценарии вступают в свои права. Вы начинаете со сценариев для создания базы данных, а затем со временем добавляете сценарии, которые изменяют базу данных по мере появления изменений - и это также применимо к вашим статическим данным (любого типа).(В конечном итоге, моя методология аналогичен бухгалтерскому учету: у вас есть учетные записи, и по мере внесения изменений вы корректируете учетные записи с помощью записей журнала. Если вы обнаружите, что допустили ошибку, вы никогда не вернетесь и не измените свои записи, вы просто сделаете последующие записи, чтобы отменить и исправить их . Это всего лишь аналогия, но логика верна.)
новый, лишенный всех этих бессмысленных данных за прошлые бесчисленные годы. Базы данных - это все об изменениях с течением времени, и именно здесь сценарии вступают в свои права. Вы начинаете со сценариев для создания базы данных, а затем со временем добавляете сценарии, которые изменяют базу данных по мере появления изменений - и это также применимо к вашим статическим данным (любого типа).(В конечном итоге, моя методология аналогичен бухгалтерскому учету: у вас есть учетные записи, и по мере внесения изменений вы корректируете учетные записи с помощью записей журнала. Если вы обнаружите, что допустили ошибку, вы никогда не вернетесь и не измените свои записи, вы просто сделаете последующие записи, чтобы отменить и исправить их . Это всего лишь аналогия, но логика верна.)
Если вы обнаружите, что допустили ошибку, вы никогда не вернетесь и не измените свои записи, вы просто сделаете последующие записи, чтобы отменить и исправить их. Это всего лишь аналогия, но логика верна.) Если вы обнаружите, что допустили ошибку, вы никогда не вернетесь и не измените свои записи, вы просто сделаете последующие записи, чтобы отменить и исправить их. Это всего лишь аналогия, но логика верна.)Решение, которое я использую, состоит в том, чтобы иметь сценарии создания и изменения в системе управления версиями вместе с информацией о версии, хранящейся в базе данных.
Затем у меня есть мастер установки, который может определить, нужно ли ему создавать или обновлять базу данных - процесс обновления управляется путем выбора соответствующих сценариев на основе информации о версии, хранящейся в базе данных.
См. ответ этой темы . Статические данные из ваших первых двух точек должны быть в системе управления версиями, IMHO.
Edit: * new
- all-in-one или отдельный скрипт? это не имеет значения, если вы (команда разработчиков ) согласитесь с командой развертывания. Я предпочитаю разделять файлы, но я всегда могу создать all-in-one.sql из них в правильном порядке
[Логины, роли, пользователи; Таблицы; Просмотры; Хранимые процедуры; UDF; Статические данные; (Таблицы аудита, Триггеры аудита)] - как убедиться, что они его выполняют : ну, сделайте это еще одним шагом в документации по развертыванию вашего приложения / базы данных. Если вы развертываете приложение, которому действительно нужны определенные (новые) статические данные в базе данных, вы можете захотеть выполнить проверку версии БД в своем приложении. и вы обновляете DB_VERSION до вашего нового номера выпуска как часть этого скрипта. Затем ваше приложение при запуске должно проверить это и сообщить об ошибке, если требуется новая версия БД.
- Статические данные для разработчиков и не для разработчиков : На самом деле я никогда не видел этого случая. Чаще всего есть настоящие статические данные , которые можно назвать "dev", что является основной конфигурацией, статическими данными ISO и т. Д. Другой тип - это поисковые данные по умолчанию , которые предназначены для пользователей для начала, но они могут добавить больше. Механизм ВСТАВКИ этих данных может быть другим, потому что вам нужно убедиться, что вы не уничтожаете (мощные) данные, созданные пользователем.
Я объяснил технику, которую использовал в своем блоге Контроль версий и ваша база данных . Я использую метаданные базы данных (в данном случае расширенные свойства SQL Server) для хранения развернутой версии приложения. У меня есть только скрипты, которые обновляются от версии к версии. При запуске приложение считывает развернутую версию из метаданных базы данных (отсутствие метаданных интерпретируется как версия 0, т. Е. Еще ничего не развернуто). Для каждой версии есть функция приложения, которая обновляется до следующей версии. Обычно эта функция запускает сценарий T-SQL внутреннего ресурса, который выполняет обновление, но это может быть что-то еще, например, развертывание сборки CLR в базе данных.
Нет сценария для развертывания «текущей» схемы базы данных. Новые выпуски проходят через все промежуточные версии, от версии 1 до текущей версии.
Эта техника дает мне несколько преимуществ:
- Мне легко тестировать новую версию. У меня есть резервная копия предыдущей версии, я применяю сценарий обновления, затем могу вернуться к предыдущей версии, изменить сценарий, повторить попытку, пока не буду доволен результатом.
- Мое приложение можно развернуть поверх из любой предыдущей версии. Разные клиенты имеют разную развернутую версию. Когда они обновляются, мое приложение поддерживает обновление любой предыдущей версии.
- Нет разницы между новой установкой и обновлением, он запускает тот же код, поэтому у меня меньше путей кода, которые нужно поддерживать и тестировать.
- Существует нет разницы между изменениями DML и DDL (ваш исходный вопрос). они все относились одинаково, по мере запуска сценария для перехода от одной версии к другой. Когда мне нужно внести изменение, как вы описываете (изменить значение по умолчанию), я фактически увеличиваю версию схемы , даже если не происходит других изменений DDL . Таким образом, в версии 5.1 значение по умолчанию было «foo», в 5.2 - «bar» , и это единственное различие между двумя версиями , а этап «обновления» - это просто оператор UPDATE (за которым следует Конечно, путем изменения метаданных версии, т.е. sp_updateextendedproperty).
- Все изменения происходят в системе управления версиями, части источников приложения (в основном сценарии T-SQL).
- Я могу легко перейти к любой предыдущей версии схемы, например. чтобы воспроизвести жалобу клиента, просто запустив последовательность обновления и остановившись на интересующей меня версии.
Этот подход несколько раз спасал мою кожу, и я ' теперь я истинно верующий. Есть только один недостаток: в исходном коде нет очевидного места, где можно найти «какова текущая форма процедуры foo?». Поскольку последняя версия foo могла быть обновлена 2 или 3 версии назад и с тех пор не менялась, мне нужно посмотреть сценарий обновления для этой версии. Обычно я просто заглядываю в базу данных и смотрю, что там, вместо того, чтобы искать в сценариях обновления.
И последнее замечание: на самом деле это не мое изобретение. Это моделируется точно по образцу того, как сам SQL Server обновляет метаданные базы данных (mssqlsystemresource).
Поскольку последняя версия foo могла быть обновлена 2 или 3 версии назад и с тех пор не менялась, мне нужно посмотреть сценарий обновления для этой версии. Обычно я просто заглядываю в базу данных и смотрю, что там, вместо того, чтобы искать в сценариях обновления.И последнее замечание: на самом деле это не мое изобретение. Это моделируется точно по образцу того, как сам SQL Server обновляет метаданные базы данных (mssqlsystemresource).
Поскольку последняя версия foo могла быть обновлена 2 или 3 версии назад и с тех пор не менялась, мне нужно посмотреть сценарий обновления для этой версии. Обычно я просто заглядываю в базу данных и смотрю, что там, вместо того, чтобы искать в сценариях обновления.И последнее замечание: на самом деле это не мое изобретение. Это моделируется точно по образцу того, как сам SQL Server обновляет метаданные базы данных (mssqlsystemresource).
Здесь, в Red Gate, мы недавно добавили функцию сравнения данных SQL, позволяющую сохранять статические данные в виде DML (один файл .sql для каждой таблицы) вместе со схемой DDL, которая в настоящее время поддерживается SQL. Сравните.
Чтобы понять, как это работает, вот диаграмма , которая объясняет, как это работает.
Идея состоит в том, что когда вы хотите отправить изменения на свой целевой сервер, вы выполняете сравнение, используя сценарии в качестве источника данных, который генерирует необходимый сценарий синхронизации DML для обновления целевого объекта. Это означает, что вам не нужно предполагать, что цель каждый раз воссоздается с нуля. Со временем мы надеемся поддерживать статические данные в нашем предстоящем инструменте управления исходным кодом SQL .
Дэвид Аткинсон, менеджер по продукту, Red Gate Software