Как Вы отслеживаете изменения базы данных в управлении исходным кодом?

Предположим, что нам нужно использовать класс Classname, который содержится в файле jar org.example.jar

И ваш источник находится в файле mysource.java Пример:

import org.example.Classname;

public class mysource {
    public static void main(String[] argv) {
    ......
   }
}

Во-первых, как видите, в коде вы должны импортировать классы. Для этого вам понадобится import org.example.Classname;

Во-вторых, при компиляции источника вам необходимо обратиться к файлу jar.

Обратите внимание на разницу в использовании : и ; при компиляции

  • Если вы находитесь под операционной системой unix:
    javac -cp '.:org.example.jar' mysource.java
    
  • Если вы находитесь под окнами:
    javac -cp .;org.example.jar mysource.java
    

После этого вы получите файл байт-кода mysource.class

Теперь вы можете запустить это:

  • Если вы находитесь под операционной системой unix:
    java -cp '.:org.example.jar' mysource
    
  • Если вы находитесь под окнами:
    java -cp .;org.example.jar mysource
    
22
задан Michael Haren 9 December 2008 в 14:28
поделиться

11 ответов

Используйте выпуск базы данных Visual Studio для сценария Ваша база данных. Работы как очарование и можно использовать любую Систему управления исходным кодом, конечно, лучше всего, если она имеет плагины VS. Этот инструмент имеет также много других полезных функций. Проверьте их здесь в это большое сообщение в блоге

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

или проверьте MSDN для официальной документации

15
ответ дан terjetyl 29 November 2019 в 05:10
поделиться

Наши dbas периодически проверяют напоминание по тому, что находится в SVN, и удалите любые объекты не при управлении исходным кодом. Это только берет однажды devlopers, никогда не забывают помещать что-то в управление исходным кодом снова.

Мы также не позволяем никому перемещать объекты подталкивать без сценария, поскольку наши devs не имеют прав напоминания, это легко осуществить.

0
ответ дан HLGEM 29 November 2019 в 05:10
поделиться

В SQL2000 генерируют каждый объект в свой собственный файл , затем проверяют их всех в Вашем управлении исходным кодом. Позвольте своему управлению исходным кодом обработать историю изменений.

В SQL 2005, необходимо будет записать немного кода для генерации всех объектов в отдельные файлы.

1
ответ дан Tom H 29 November 2019 в 05:10
поделиться

В одном проекте я расположил внимательным отношением в дизайне, что все важные данные в базе данных могут быть автоматически воссозданы от внешних мест. При запуске приложение создает базу данных, если это отсутствует и заполняет его от внешних источников данных, с помощью схемы в исходном коде приложения (и следовательно имеющий версию с приложением). Название магазина базы данных (sqlite имя файла, хотя большинство менеджеров базы данных позволяет несколько баз данных) включает версию схемы, и мы увеличиваем версию схемы каждый раз, когда мы фиксируем изменение схемы. Это означает, когда мы перезапускаем приложение к новой версии с различной схемой, что новое хранилище базы данных автоматически создается и заполняется. Если мы должны вернуться развертывание на старой схеме тогда, новое выполнение старой версии будет использовать старое хранилище базы данных, таким образом, мы доберемся, чтобы сделать быстрые снижения в случае проблемы.

По существу, база данных действует как "куча" традиционного приложения, с преимуществами персистентности, безопасности транзакции, статический контроль типов (удобный, так как мы используем Python), и ограничения уникальности. Однако мы не волнуемся вообще об удалении базы данных и запуске, и люди знают, что, если они пробуют некоторый ручной взлом в базе данных тогда, это вернется на следующем развертывании, во многом как взломы процесса, состояние вернется на следующем перезапуске.

Нам не нужны никакие сценарии миграции, так как мы просто переключаем имя файла базы данных и перезапускаем приложение, и это восстанавливает себя. Помогает, что экземпляры приложения являются черепком для использования одной базы данных на клиент. Это также уменьшает потребность в резервных копиях базы данных.

Этот подход не будет работать, если Ваша сборка базы данных из внешних источников займет больше времени, чем Вы позволите приложению быть, остаются вниз.

0
ответ дан Dickon Reed 29 November 2019 в 05:10
поделиться

Прокрутка Ваше собственное с нуля не было бы очень выполнимым, но если Вы используете sql инструмент сравнения как SQL Redgate, Сравнивает SDK для генерации файлов изменения для Вас, это не брало бы очень долго к перевороту через крыло, что Вы хотите и затем просто проверяете те файлы в управлении исходным кодом. Я прокрутил что-то подобное для меня для обновления изменений от наших систем разработки до наших живых систем всего за несколько часов.

1
ответ дан MonkeyBrother 29 November 2019 в 05:10
поделиться

Я просто фиксирую дополнительное SQL-alter-Statement полному SQL-CreateDB-statement.

1
ответ дан berlindev 29 November 2019 в 05:10
поделиться

Решение одного бедного человека состояло бы в том, чтобы добавить сценарий рычага перед фиксацией, который разгрузил последнюю схему дб в файл, и согласитесь на тот файл Ваш репозиторий SVN наряду с Вашим кодом. Затем Вы можете разность файлы схемы дб от любого пересмотра.

3
ответ дан Marcus 29 November 2019 в 05:10
поделиться

Я должен сказать, что думаю, что проект базы данных Visual Studio является также разумным решением дилеммы управления исходным кодом. Если это настраивается правильно, можно выполнить сценарии против базы данных от IDE. Если Ваш сценарий стар, получите последнее, выполните его против DB. Имейте сценарий, который воссоздает все объекты также, если Вам нужно, новые объекты должны быть добавлены к этому сценарию также вручную, но только однажды

мне нравится, когда каждая таблица, proc и функция находятся в своем собственном файле.

5
ответ дан Robert 29 November 2019 в 05:10
поделиться

В нашей среде мы никогда не изменяем DB вручную: все изменения сделаны сценариями во время выпуска, и сценарии сохранены в системе управления версиями. Одна важная часть этой процедуры должна быть уверена, что все сценарии могут быть выполнены снова против того же DB, сценарии являются идемпотентом?) без потери данных. Например, если Вы добавляете столбец, удостоверьтесь, что Вы ничего не делаете, если столбец уже там.

Ваш комментарий о "предложениях имеет дефект, что они требуют, чтобы dev для выполнения некоторой процедуры" был действительно болтуном. Это не дефект, это - функция. Управление версиями помогает разработчикам в следующих процедурах и делает процедуры менее болезненными. Если Вы не хотите выполнять процедуры, Вам не нужно управление версиями.

1
ответ дан 29 November 2019 в 05:10
поделиться

Мы разработали специальный инструмент для обновления наших баз данных. Схема базы данных хранится в нейтральном к базе данных XML-файле, который затем считывается и обрабатывается инструментом. Схема сохраняется в SVN, и мы добавляем соответствующий комментарий, чтобы показать, что было изменено. У нас это работает очень хорошо.

Хотя такого рода решение определенно является излишним для большинства проектов, оно определенно облегчает жизнь в разы.

0
ответ дан 29 November 2019 в 05:10
поделиться

Если вы используете .Net и вам нравится подход Rails к миграции, то я бы порекомендовал Migrator.Net .

Я нашел хороший учебник , который описывает его настройку в Visual Studio. Он также предоставляет образец проекта для справки.

0
ответ дан 29 November 2019 в 05:10
поделиться
Другие вопросы по тегам:

Похожие вопросы: