Сохраненная схема процедур/DB в управлении исходным кодом

Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:

TypeA objA;

. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.

См. Также этот пример:

String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
68
задан Abe Miessler 8 November 2010 в 22:05
поделиться

19 ответов

Мы принимаем решение написать сценарий всего, и это включает все хранимые процедуры и изменения схемы. Нет WYSIWYG инструменты и никакие необычные 'синхронизирующие' программы необходимы.

изменения Схемы легки, все, что необходимо сделать, создают и поддерживают единственный файл для той версии, включая всю схему и изменения данных. Это становится Вашим сценарием преобразования от версии x до x+1. Можно тогда выполнить его против производственного резервного копирования и интегрировать это в 'ежедневную сборку', чтобы проверить, что это работает без ошибок. Обратите внимание, что важно не изменить или уже удалить записанную схему / загрузка данных sql, поскольку можно закончить тем, что повредили любой sql, записанный позже.

-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO

-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO

Для хранимых процедур, мы выбираем для единственного файла на sproc, и он использует отбрасывать/создавать форму. Все хранимые процедуры воссоздаются при развертывании. Оборотная сторона - то, что, если изменение было сделано вне управления исходным кодом, изменение потеряно. В то же время, это правда для любого кода, но Вашего DBA'a должен знать об этом. Это действительно останавливает людей вне команды, унавоживающей с Вашими хранимыми процедурами, поскольку их изменения потеряны в обновлении.

Используя SQL-сервер, синтаксис похож на это:

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO

CREATE PROCEDURE [usp_MyProc]
(
    @UserID INT
)
AS

SET NOCOUNT ON

-- stored procedure logic.

SET NOCOUNT OFF

GO  

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

Как позитивный аспект к сценариям всего, Вы станете намного лучше в чтении и записи SQL. Можно также сделать этот весь процесс более тщательно продуманным, но это - основной формат как к управлению исходным кодом весь sql без любого специального программного обеспечения.

приложение: Rick корректен, который Вы потеряете, полномочия на хранимых процедурах с ОТБРАСЫВАЮТ/СОЗДАЮТ, таким образом, Вы, возможно, должны записать, что другой сценарий повторно включит определенные полномочия. Этот сценарий разрешения был бы последним для выполнения. Наш опыт нашел, что больше проблем с ИЗМЕНЯЕТСЯ, стихи ОТБРАСЫВАЮТ/СОЗДАЮТ семантику. YMMV

43
ответ дан Robert Paulson 24 November 2019 в 14:21
поделиться

Я выполняю задание для сценариев его к формальной структуре каталогов.

следующее является кодом VS2005, проектом командной строки, названным от пакетного файла, который делает работу. ключи app.config в конце кода.

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

Imports Microsoft.VisualStudio.SourceSafe.Interop
Imports System
Imports System.Configuration

Module Module1

    Dim sourcesafeDataBase As String, sourcesafeUserName As String, sourcesafePassword As String, sourcesafeProjectName As String, fileFolderName As String


    Sub Main()
        If My.Application.CommandLineArgs.Count > 0 Then
            GetSetup()
            For Each thisOption As String In My.Application.CommandLineArgs
                Select Case thisOption.ToUpper
                    Case "CHECKIN"
                        DoCheckIn()
                    Case "CHECKOUT"
                        DoCheckOut()
                    Case Else
                        DisplayUsage()
                End Select
            Next
        Else
            DisplayUsage()
        End If
    End Sub

    Sub DisplayUsage()
        Console.Write(System.Environment.NewLine + "Usage: SourceSafeUpdater option" + System.Environment.NewLine + _
            "CheckIn - Check in ( and adds any new ) files in the directory specified in .config" + System.Environment.NewLine + _
            "CheckOut - Check out all files in the directory specified in .config" + System.Environment.NewLine + System.Environment.NewLine)
    End Sub

    Sub AddNewItems()
        Dim db As New VSSDatabase
        db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword)
        Dim Proj As VSSItem
        Dim Flags As Integer = VSSFlags.VSSFLAG_DELTAYES + VSSFlags.VSSFLAG_RECURSYES + VSSFlags.VSSFLAG_DELNO
        Try
            Proj = db.VSSItem(sourcesafeProjectName, False)
            Proj.Add(fileFolderName, "", Flags)
        Catch ex As Exception
            If Not ex.Message.ToString.ToLower.IndexOf("already exists") > 0 Then
                Console.Write(ex.Message)
            End If
        End Try
        Proj = Nothing
        db = Nothing
    End Sub

    Sub DoCheckIn()
        AddNewItems()
        Dim db As New VSSDatabase
        db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword)
        Dim Proj As VSSItem
        Dim Flags As Integer = VSSFlags.VSSFLAG_DELTAYES + VSSFlags.VSSFLAG_UPDUPDATE + VSSFlags.VSSFLAG_FORCEDIRYES + VSSFlags.VSSFLAG_RECURSYES
        Proj = db.VSSItem(sourcesafeProjectName, False)
        Proj.Checkin("", fileFolderName, Flags)
        Dim File As String
        For Each File In My.Computer.FileSystem.GetFiles(fileFolderName)
            Try
                Proj.Add(fileFolderName + File)
            Catch ex As Exception
                If Not ex.Message.ToString.ToLower.IndexOf("access code") > 0 Then
                    Console.Write(ex.Message)
                End If
            End Try
        Next
        Proj = Nothing
        db = Nothing
    End Sub

    Sub DoCheckOut()
        Dim db As New VSSDatabase
        db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword)
        Dim Proj As VSSItem
        Dim Flags As Integer = VSSFlags.VSSFLAG_REPREPLACE + VSSFlags.VSSFLAG_RECURSYES
        Proj = db.VSSItem(sourcesafeProjectName, False)
        Proj.Checkout("", fileFolderName, Flags)
        Proj = Nothing
        db = Nothing
    End Sub

    Sub GetSetup()
        sourcesafeDataBase = ConfigurationManager.AppSettings("sourcesafeDataBase")
        sourcesafeUserName = ConfigurationManager.AppSettings("sourcesafeUserName")
        sourcesafePassword = ConfigurationManager.AppSettings("sourcesafePassword")
        sourcesafeProjectName = ConfigurationManager.AppSettings("sourcesafeProjectName")
        fileFolderName = ConfigurationManager.AppSettings("fileFolderName")

    End Sub

End Module



<add key="sourcesafeDataBase" value="C:\wherever\srcsafe.ini"/>
<add key="sourcesafeUserName" value="vssautomateuserid"/>
<add key="sourcesafePassword" value="pw"/>
<add key="sourcesafeProjectName" value="$/where/you/want/it"/>
<add key="fileFolderName" value="d:\yourdirstructure"/>
0
ответ дан 24 November 2019 в 14:21
поделиться

Мы храним все связанное с приложением в нашем SCM. Сценарии DB обычно хранят в их собственном проекте, но рассматривают точно так же, как любой другой код... разрабатывают, реализуют, тестируют, фиксация.

0
ответ дан Chris Hall 24 November 2019 в 14:21
поделиться

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

0
ответ дан Rikalous 24 November 2019 в 14:21
поделиться

Я настоятельно рекомендую схему поддержания и хранимые процедуры в управлении исходным кодом.

имеющие версию хранимые процедуры Хранения позволяет им откатываться, когда определено быть проблематичным.

Схема является менее очевидным ответом в зависимости от того, что Вы имеете в виду. Очень полезно поддержать SQL, который определяет Ваши таблицы в управлении исходным кодом для дублирования сред (prod/dev/user и т.д.).

0
ответ дан 24 November 2019 в 14:21
поделиться

Мы действительно сохраняем хранимые процедуры в управлении исходным кодом. Путем мы (или по крайней мере I) делаем это, добавляет папка к моему проекту, добавляет файл для каждого SP и вручную копирует, вставляет код в него. Таким образом, когда я изменяю SP, я вручную должен изменить файл управление исходным кодом.

мне было бы интересно слышать, могут ли люди сделать это автоматически.

0
ответ дан Rik 24 November 2019 в 14:21
поделиться

Для procs запишите procs с обертками сценария в простые файлы и примените изменения из тех файлов. Если это применялось правильно, то можно зарегистрироваться в том файле, и Вы сможете воспроизвести его из того файла также.

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

0
ответ дан John Flinchbaugh 24 November 2019 в 14:21
поделиться

Напишите сценарий всего (создание объекта, и т.д.) и сохраните те сценарии в управлении исходным кодом. Как изменения добираются там? Это - часть общепринятой практики того, как сделаны вещи. Потребность добавить таблицу? Запишите сценарий CREATE TABLE. Обновить sproc? Отредактируйте сценарий хранимой процедуры.

я предпочитаю один сценарий на объект.

0
ответ дан ahockley 24 November 2019 в 14:21
поделиться

Мы сохраняем хранимые процедуры в управлении исходным кодом.

0
ответ дан Darren Kopp 24 November 2019 в 14:21
поделиться

В моей компании мы склонны хранить все объекты базы данных в управлении исходным кодом как отдельные сценарии, как Вы были бы для отдельных файлов кода. Любые обновления сначала сделаны в базе данных и затем перемещены в репозиторий исходного кода, таким образом, история изменений сохраняется.
Как второй шаг, все изменения базы данных перемещены в базу данных интеграции. Эта база данных интеграции представляет точно, что производственная база данных должна быть похожей на развертывание сообщения. У нас также есть база данных QA, которая представляет текущее состояние производства (или последнее развертывание). Как только все изменения внесены в базе данных Integration, мы используем инструмент разности схемы (Разность SQL Красного Логического элемента для SQL Server) для генерации сценария, который переместит все изменения от одной базы данных до другого.
Мы нашли, что это довольно эффективно, поскольку это генерирует единственный сценарий, который мы можем интегрировать с нашими установщиками легко. Самой большой проблемой, которую мы часто имеем, являются разработчики, забывающие перемещать их изменения в интеграцию.

1
ответ дан 24 November 2019 в 14:21
поделиться

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

Мы сохранили бы сценарии в управлении исходным кодом следующим образом (структура папок ниже):

я немного ржав на текущих соглашениях о присвоении имен по таблицам и хранимых процедурах, таким образом пустых с моим примером...

[корень]
        [приложение]
                [версия]
                        [сценарий]

\scripts
        MyApplication \
                1.2.1 \
                        001. MyTable. Create.sql
                        002. MyOtherTable. Create.sql
                        100.dbo.usp. MyTable. GetAllNewStuff.sql

С использованием таблицы Versions, которая приняла бы во внимание Приложение и Присвоила бы версию приложению, восстановит еженедельное производственное резервное копирование и выполнит все сценарии, необходимые против базы данных начиная с текущей версии. При помощи .net мы легко смогли упаковать это в транзакцию и если бы что-нибудь перестало работать, то мы откатывали бы и послали бы электронные письма, таким образом, мы знали, что выпуск имел плохие сценарии.

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

Это - вероятно, больше информации, чем Вы искали, но она работала очень хорошо на нас, и, учитывая структуру было легко получить всех разработчиков на борту.

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

2
ответ дан Dean Poulin 24 November 2019 в 14:21
поделиться

Подобный Robert Paulson, выше, наша организация сохраняет базу данных при управлении исходным кодом. Однако наше различие - то, что мы пытаемся ограничить количество сценариев, которые мы имеем.

Для любого нового проекта, существует процедура набора. У нас есть сценарий создания схемы в версии 1, сохраненный proc сценарий создания и возможно, исходные данные загружают сценарий создания. Все procs сохранены в единственном, по общему признанию крупном файле. Если мы пользуемся Библиотекой Предприятия, мы включаем копию сценария создания для входа; если это - проект ASP.NET использование среды разработки приложения ASP.NET (аутентификация, персонализация, и т.д.), мы включаем тот сценарий также. (Мы генерировали его от инструментов Microsoft, затем настроили его, пока это не работало воспроизводимым способом через различные сайты. Не забава, но инвестиции бесценного времени.)

Мы используем волшебный CTRL+F для нахождения proc, который мы любим.:) (Мы любили бы его, если Studio управления SQL имел навигацию кода как VS, делает. Вздохните!)

Для последующих версий, у нас обычно есть upgradeSchema, upgradeProc и/или updateDate сценарии. Для обновлений схемы мы изменяем таблицы как можно больше, создавая новые по мере необходимости. Для обновлений proc мы ОТБРАСЫВАЕМ и СОЗДАЕМ.

Одна морщина действительно открывается с этим подходом. Легко генерировать базу данных, и легко получить новое до скорости на текущей версии DB. Однако заботу нужно соблюдать о поколении DAL (который мы в настоящее время - обычно - делаем с SubSonic), чтобы гарантировать, что изменения DB/schema/proc синхронизируются чисто с кодом, используемым для доступа к ним. Однако в нашей сборке пути являются пакетным файлом, который генерирует SubSonic DAL, таким образом, это - наш SOP к контролю код DAL, повторно выполняет тот пакетный файл, затем перепроверяет все это в в любое время изменении procs и/или схеме. (Это, конечно, инициировало исходную сборку, обновляя совместно использованные зависимости к соответствующему DLLs...)

2
ответ дан John Rudy 24 November 2019 в 14:21
поделиться

Свяжите другие точки зрения на основе моего опыта. В мире Oracle всем управляли, "создают" сценарии DDL. Как ahockley упомянутый, один сценарий для каждого объекта. Если объект должен измениться, его сценарий DDL изменяется. Существует один сценарий обертки, который вызывает все объектные сценарии так, чтобы можно было развернуть текущую сборку DB на любой среде, которую Вы хотите. Это для процессорного ядра, создают.

, Очевидно, в работающем приложении, каждый раз, когда Вы продвигаете новую сборку, которая требует, скажем, нового столбца, Вы не собираетесь отбрасывать таблицу и создавать ее новый. Вы собираетесь сделать ИЗМЕНИТЬ сценарий и добавить столбец. Так каждый раз этот вид изменения должен произойти, всегда существует две вещи сделать: 1) запишите изменить DDL и 2) обновление ядро создает DDL для отражения изменения. Оба входят в управление исходным кодом, но сингл изменяется, сценарий является большим количеством мгновенного изменения момента времени, так как это будет только использоваться для применения дельты.

Вы могли также использовать инструмент как ERWin, чтобы обновить модель и вперед генерировать DDL, но большинство DBAs, которые я знаю, не доверяет инструмент моделирования генералу сценарий точно способ, которым они хотят. Вы могли также использовать ERWin для инженерного анализа базового сценария DDL в модель периодически, но это - много суеты, чтобы заставить его выглядеть правильным (в каждый уничтоженный раз, когда Вы делаете это).

В мире Microsoft, мы использовали подобную тактику, но мы использовали Красный продукт Логического элемента, чтобы помочь управлять сценариями и дельтами. Все еще поместите сценарии в управление исходным кодом. Тем не менее один сценарий на объект (таблица, sproc, безотносительно). В начале некоторые DBAs действительно предпочли использовать GUI SQL Server для управления сценариями использования, а не объектами. Но это сделало очень трудным последовательно управлять предприятием, как это выросло.

, Если DDL находится в управлении исходным кодом, это тривиально для использования любого инструмента сборки (обычно муравей) для записи сценария развертывания.

3
ответ дан Ed Lucas 24 November 2019 в 14:21
поделиться

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

4
ответ дан Adrian Mouat 24 November 2019 в 14:21
поделиться

Я соглашаюсь с (и upvote) практика Robert Paulson. Это предполагает, что Вы управляете группой разработчиков с ответственностью и дисциплиной для соблюдения такой практики.

Для "вызывания" этого на мои команды наши решения поддерживают по крайней мере один проект базы данных от [1 113] Выпуск Команды Visual Studio для Профессионалов Базы данных . Как с другими проектами в решении, проект базы данных получает имеющий версию контроль. Это делает его естественным процессом разработки для повреждения всего в базе данных в удобные в сопровождении блоки, "дисциплинируя" мою команду по пути.

, Конечно, будучи проектом Visual Studio, это не где почти прекрасно. Существует много причуд, с которыми Вы столкнетесь, который может расстроить или смутить Вас. Требуется маленькое понимание, как проект работает прежде, чем заставить его выполнять Ваши задачи. Примеры включают

, Но для команд, у которых нет практики управления версиями их объектами базы данных, это - хорошее начало. Другая известная альтернатива, конечно, комплект Красного Логического элемента продуктов SQL Server , который большинство людей, которые используют их, считает выше предложения Microsoft.

5
ответ дан icelava 24 November 2019 в 14:21
поделиться

Одна вещь иметь в виду с Вашим отбрасывала/создавала сценарии в SQL Server состоит в том, что полномочия уровня объектов будут потеряны. Мы изменились, наш стандарт для использования ИЗМЕНЯЮТ сценарии вместо этого, который поддерживает те полномочия.

существует несколько других протестов, как то, что отбрасывание объекта отбрасывает записи зависимости, используемые sp_depends, и создание объекта только создает зависимости для того объекта. Таким образом, если Вы отбросите/создадите представление, то sp_depends больше не будет знать ни о каких объектах, ссылающихся на то представление.

Мораль истории, использование ИЗМЕНЯЕТ сценарии.

5
ответ дан Rick 24 November 2019 в 14:21
поделиться

Решение, которое мы использовали в моем последнем задании, состояло в том, чтобы пронумеровать сценарии, поскольку они были добавлены к управлению исходным кодом:

01. CreateUserTable.sql
02. PopulateUserTable
03. AlterUserTable.sql
04. CreateOrderTable.sql

, которым идея состояла в том, что мы всегда знали, какой порядок выполнить сценарии, и мы могли избежать необходимости управлять проблемами целостности данных, которые могли бы возникнуть, если бы Вы пытались изменить сценарий № 1 (который был бы возможная причина ВСТАВКИ в № 2 для сбоя).

8
ответ дан Ranhiru Jude Cooray 24 November 2019 в 14:21
поделиться

создайте "Проект базы данных" в Visual Studio, чтобы записать и управлять Вашим кодом SQL и сохранить проект при управлении версиями вместе с остальной частью Вашего решения.

8
ответ дан Manu 24 November 2019 в 14:21
поделиться

Хранимые процедуры получают 1 файл на SP со стандартом, если существуют, отбрасывают/создают операторы наверху. Представления и функции также получают свои собственные файлы, таким образом, они легче к версии и повторному использованию.

Схема является всем 1 сценарием для начала тогда, мы сделаем изменения версии.

Все это хранится в проекте базы данных Visual Studio, подключенном к TFS (работа или Сервер VisualSVN домой для персонального материала) со структурой папок следующим образом:
- проект
- функции
- схема
- хранимые процедуры
- представления

1
ответ дан knight0323 24 November 2019 в 14:21
поделиться
Другие вопросы по тегам:

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