Волею судеб стал разработчиком довольно большого проекта. Большого в плане баз данных. Ну как большого — 9 баз разного размера, в нескольких из них сотни таблиц, view, процедуры тоже есть, в общем не просто данные, код тоже присутствует, 11 (!) linked servers, которые мне, к счастью удалось перелинковать на один и тот же физический и вроде все работает. Крутится это все на MSSQL 2008R2.
Т.к. я не настоящий сварщик и это самый крупный проект в смысле баз данных, которые мне в руки попадали, я не очень понимаю, как мне вообще, тсскзать, take ownership тут. До меня его разрабатывал один разработчик, к базам данных там было в комплекте несколько .net и c++ приложений (тут используется .net 3.5 и 2010 студия). Код приложений хранился в локальном svn репозитории и с ним было все нормально. А вот код для баз данных не хранился нигде. Человек просто писал скрипты изменений и рассылал их по почте заинтересованным людям, т.е. никакой версионности не было вообще.
Теперь прихожу я и мне как-то не очень нравится рассылать скрипты по почте.
Подскажите, пожалуйста, кто что может:
— как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?)
— как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них?
— как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть?
— имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как.
Здравствуйте, Ilias, Вы писали:
I>Здравствуйте,
I>Волею судеб стал разработчиком довольно большого проекта. Большого в плане баз данных. Ну как большого — 9 баз разного размера, в нескольких из них сотни таблиц, view, процедуры тоже есть, в общем не просто данные, код тоже присутствует, 11 (!) linked servers, которые мне, к счастью удалось перелинковать на один и тот же физический и вроде все работает. Крутится это все на MSSQL 2008R2.
I>Т.к. я не настоящий сварщик и это самый крупный проект в смысле баз данных, которые мне в руки попадали, я не очень понимаю, как мне вообще, тсскзать, take ownership тут. До меня его разрабатывал один разработчик, к базам данных там было в комплекте несколько .net и c++ приложений (тут используется .net 3.5 и 2010 студия). Код приложений хранился в локальном svn репозитории и с ним было все нормально. А вот код для баз данных не хранился нигде. Человек просто писал скрипты изменений и рассылал их по почте заинтересованным людям, т.е. никакой версионности не было вообще.
С версией SQL Server 2012 вышел инструмент SQL Server Data Tools (SSDT) под кодовым названием Juneau. Проект начал свое хождение начиная с версии Visual Studio 2010, призван заменить старые vsdb проекты, которые вы упоминали, фактически является инструментом разработчика (администратора) БД MS SQL Server для версий 2005 и выше. SSDT представляет собой бесплатное расширение студии, которое позволяет создавать реляционные базы данных. Кроме всего прочего позволяет работать со всем стеком BI от Microsoft (SSIS, SSAS, SSRS). О возможностях я вскользь упоминал например здесь
, более детально с продуктом можно ознакомиться по документации ну и на основании личного опыта. В наши дни поддержка версии для 2010 студии не ведется, но дистрибутив с последними изменениям я думаю можно найти.
I>Теперь прихожу я и мне как-то не очень нравится рассылать скрипты по почте. I>Подскажите, пожалуйста, кто что может: I>- как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?)
Код БД может хранится в SSDT проекте в рамках большого солюшона студии с .Net, C++ и Web приложениями. Код — это объекты БД и сервера на языке T-SQL.
I>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них?
Предложу один из вариантов, их может быть масса. Создаете в этом же проекте PostDeployment скрипт — он может быть один. В этом скрипте вы управляете своими данными, например справочниками. Выглядит это так:
insert into dbo.Table(Id, Name) select 1, 'Привет 1'
insert into dbo.Table(Id, Name) select 2, 'Привет 2'
go
insert into dbo.Table1(Id, Name) select 1, 'Hello 1'
insert into dbo.Table1(Id, Name) select 1, 'Hello 2'
go
Перед выпуском версии вам необходимо выполнить build проекта и опубликовать его локально. Для этих целей на рабочую станцию вместе с SSDT ставится версия LocalDB, которая позволяет вести разработку в так называемом offline режиме. Далее, используя Data Compare вы можете сравнить данные вашей локальной версии БД и тестовой/сертификационной среды. На основании сравнения SSDT сгенерирует вам скрипт, в зависимости от состава данных.
I>- как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть?
Используя SSDT, вы можете выбрать объект БД и нажав на правую кнопку мыши, выбрать пункт References Студия по аналогии с .Net приложениями например, покажет вам ссылки во всех объектах БД, где он упоминается. Исключение составляет динамический SQL sp_executesql 'select * from dbo.Table', здесь студия бессильна.
I>- имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как.
Все зависит от того как у вас выстроен процесс выпуска и обновления версий и кто этим занимается. Одно время мы практиковали простой вариант. Приложение и БД имеют major и minor версию. Весь комплекс работает только в том случае, если major версия приложения и БД совпадает. Minor версия может расходиться и это оставляет возможность обновления приложения без БД и наоборот, но при этом изменения одновременно не затрагивают и БД и приложение, в противном случае смена major версии. В свое время этого было достаточно. К этой схеме можно подключить build и revision версии.
O>Используя SSDT, вы можете выбрать объект БД и нажав на правую кнопку мыши, выбрать пункт References Студия по аналогии с .Net приложениями например, покажет вам ссылки во всех объектах БД, где он упоминается. Исключение составляет динамический SQL sp_executesql 'select * from dbo.Table', здесь студия бессильна.
Старый добрый grep существует с 70-х и поможет там где студия бессильна!
O>С версией SQL Server 2012 вышел инструмент SQL Server Data Tools (SSDT) под кодовым названием Juneau. Проект начал свое хождение начиная с версии Visual Studio 2010, призван заменить старые vsdb проекты, которые вы упоминали, фактически является инструментом разработчика (администратора) БД MS SQL Server для версий 2005 и выше. SSDT представляет собой бесплатное расширение студии, которое позволяет создавать реляционные базы данных. Кроме всего прочего позволяет работать со всем стеком BI от Microsoft (SSIS, SSAS, SSRS). О возможностях я вскользь упоминал например здесь
, более детально с продуктом можно ознакомиться по документации ну и на основании личного опыта. В наши дни поддержка версии для 2010 студии не ведется, но дистрибутив с последними изменениям я думаю можно найти.
спасибо, посмотрю на него. похоже он чуть лучше чем существующие проекты баз данных.
I>>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них?
O>Предложу один из вариантов, их может быть масса. Создаете в этом же проекте PostDeployment скрипт — он может быть один. В этом скрипте вы управляете своими данными, например справочниками. Выглядит это так: O>
O>insert into dbo.Table(Id, Name) select 1, 'Привет 1'
O>insert into dbo.Table(Id, Name) select 2, 'Привет 2'
O>go
O>insert into dbo.Table1(Id, Name) select 1, 'Hello 1'
O>insert into dbo.Table1(Id, Name) select 1, 'Hello 2'
O>go
O>
O>Перед выпуском версии вам необходимо выполнить build проекта и опубликовать его локально. Для этих целей на рабочую станцию вместе с SSDT ставится версия LocalDB, которая позволяет вести разработку в так называемом offline режиме. Далее, используя Data Compare вы можете сравнить данные вашей локальной версии БД и тестовой/сертификационной среды. На основании сравнения SSDT сгенерирует вам скрипт, в зависимости от состава данных.
тут вопрос был скорее про то, что база данных сейчас уже какая-то есть. и в ней не только таблицы, но и данные, которые как-то надо мигрировать со старой версии на новую. некоторые базы довольно большие (3-4 гигабайта), в текстовые скрипты их не положишь. т.е. два варианта — установка на чистую машину (для разработчика) и обновление уже существующей базы с данными до последней версии.
Здравствуйте, Олег К., Вы писали:
O>>Используя SSDT, вы можете выбрать объект БД и нажав на правую кнопку мыши, выбрать пункт References Студия по аналогии с .Net приложениями например, покажет вам ссылки во всех объектах БД, где он упоминается. Исключение составляет динамический SQL sp_executesql 'select * from dbo.Table', здесь студия бессильна.
ОК>Старый добрый grep существует с 70-х и поможет там где студия бессильна!
старый добрый греп не поможет в таких случаях
var sp = "sp_getDataFromTable_";
...
DataTable res = null;
if(flag)
res = executeQuery(sp+"Plain");
else
res = executeQuery(sp+"Suppa");
...
Здравствуйте, Ilias, Вы писали:
I>тут вопрос был скорее про то, что база данных сейчас уже какая-то есть. и в ней не только таблицы, но и данные, которые как-то надо мигрировать со старой версии на новую. некоторые базы довольно большие (3-4 гигабайта), в текстовые скрипты их не положишь. т.е. два варианта — установка на чистую машину (для разработчика) и обновление уже существующей базы с данными до последней версии.
Как правило в самом проекте хранятся данные, которые обеспечивают доменную целостность, причем их нет так много по количеству, создаются они руками в формате insert into и очень редко подлежат изменению. Но если задача более масштабная и нужно синхронизировать (распространять) миллионы записей, то можно поступить следующим образом.
Создается эталонная БД, которая является подмножеством основной БД и содержит в схеме только те объекты, которые подлежат сравнению, распространению. Пользователи, приложения и другие модули системы генерируют данные на эталоне, например у нас по отдельным таблицам количество достигало 50 млн. записей. Эталонная БД в виде mdf файла (или бэкапа) в случае необходимости добавляется в дистрибутив. Перед выполнением обновления данная БД подключается на SQL сервер рядом с основной БД, которая подлежит обновлению. В скрипт перехода, в том числе входят запросы, которые сравнивают данные между двумя базами и выполняют в зависимости от сценария CRUD операции. При желании процесс обновления можно автоматизировать по максимуму.
ОК>>Ты, чувак, вообще разбей все строки на массивы букв — 'h', 'e', 'l', 'l', 'o' — тогда тебе вообще ничто не поможет!
I>Я, чувак, так код не пишу. Это, чувак, та хрень, которая мне досталась по наследству. То, чувак, с чем работать приходится.
А ты, чувак, не придумал это сейчас? Я видел много невменяемого кода, но вот чтобы программисткие сущности (по которым можно делать поиск в файлах) разбивались на подстроки, такого не видел. Тот пример что ты привел — это надо быть невменяемым совсем чтобы так писать.
Здравствуйте, Олег К., Вы писали:
ОК>Я видел много невменяемого кода, но вот чтобы программисткие сущности (по которым можно делать поиск в файлах) разбивались на подстроки, такого не видел.
Это называется динамический SQL, а в общем случае — кодогенерация.
ОК>Тот пример что ты привел — это надо быть невменяемым совсем чтобы так писать.
Данный пример возможно и дебильный (мы не знаем контекст), но не нужно огульно обобщать.
ОК>>Я видел много невменяемого кода, но вот чтобы программисткие сущности (по которым можно делать поиск в файлах) разбивались на подстроки, такого не видел.
W>Это называется динамический SQL, а в общем случае — кодогенерация.
И что? Речь шла не о динамическом сиквеле, а о разбивке названия функция. Ну и, естественно же, что и в генерирущем коде и в генерируемом названия функции должны всегда писаться слитно чтобы избежать таких ситуаций.
ОК>>Тот пример что ты привел — это надо быть невменяемым совсем чтобы так писать.
W>Данный пример возможно и дебильный (мы не знаем контекст), но не нужно огульно обобщать.
Ты сам честно ответь: видел ты такое за свою работу программистом? Я, вот, ни разу не видел чтобы кто-то разбивал название функции как это сделал он в своем примере. Бывает что предложение или фразу не получается сразу найти из-за конкатенации строк, но это совсем другой случай. Он же утверждает что у него в проекте разбивка названий функций случается сплошь и рядом. Я в этом сильно сомневаюсь.
I>- как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?)
по доброй воле я бы не стал
I>- как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть?
Посмотри на http://www.red-gate.com, все остальное почти наверняка будет хуже
I>- имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как. I>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них?
Да, определенно имеет. Вообще это довольно сложная задача, если ее решать хорошо, но как я понял несколько мес на "хорошо" нет, поэтому посмотри опять же на ред-гейтовские продукты.
Здравствуйте, Олег К., Вы писали:
ОК>Ты сам честно ответь: видел ты такое за свою работу программистом? Я, вот, ни разу не видел чтобы кто-то разбивал название функции как это сделал он в своем примере. Бывает что предложение или фразу не получается сразу найти из-за конкатенации строк, но это совсем другой случай. Он же утверждает что у него в проекте разбивка названий функций случается сплошь и рядом. Я в этом сильно сомневаюсь.
Банально нарезали таблицы по годам. А номер или диапазон года вообще в процедуру параметрами приходит. Не сталкивались?
Здравствуйте, Олег К., Вы писали:
ОК>Ты сам честно ответь: видел ты такое за свою работу программистом? Я, вот, ни разу не видел чтобы кто-то разбивал название функции как это сделал он в своем примере.
Имена таблиц с префиксами/суффиксами видел? А функция в данном случае это обертка для таблицы или нескольких.
Здравствуйте, Олег К., Вы писали:
ОК>Видел, но, опять-таки, в случае такого дизайна, искать нужно по имени таблицы без года. По-моему это очевидно.
Ну где же ваша фантазия! Стоит только оставить общий префикс для динамических таблиц с нормальными, первым параметром — имя сущности, вторым — вид анализа — и воля — имя таблицы неотличимо от таблицы ядра.
А если DBA перестал всем по рукам бить за кривые скрипты — то не потому что стал добрым, а потому что устал (ну вы поняли). И потом в процах находятся настолько чудесные вещи, что выкидываешь, если еще не поздно и переписываешь.
Здравствуйте, rm822, Вы писали:
I>>- как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?) R>по доброй воле я бы не стал
I>>- как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть? R>Посмотри на http://www.red-gate.com, все остальное почти наверняка будет хуже
I>>- имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как. I>>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них? R>Да, определенно имеет. Вообще это довольно сложная задача, если ее решать хорошо, но как я понял несколько мес на "хорошо" нет, поэтому посмотри опять же на ред-гейтовские продукты.
да про время не понятно пока. как я понимаю, до меня с этим счастьем работал один человек плюс еще один-два работали с c++ утилитами. они остаются, а этот один человек уходит. так что, скорее всего мне будут просто давать задания по функционалу. а между ними, я очень надеюсь, будет какое-то время для приведения этого всего в порядок. то, что будет рефакторинг c# части это уже точно, а тут я пытаюсь понять что можно сделать с базами данных.
I>Теперь прихожу я и мне как-то не очень нравится рассылать скрипты по почте. I>Подскажите, пожалуйста, кто что может: I>- как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?) I>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них? I>- как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть? I>- имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как.
I>Спасибо
Для начала нужно запретить обновллять БД у тестировщиков с помощью скриптов и прочих человеческих факторов. Только GUI, собранной на билд сервере.
Приложения должны graceful показывать ВСЕМ пользователям что БД сломана и слать на администратора. Не знаю как по-русски graceful
VC>Для начала нужно запретить обновллять БД у тестировщиков с помощью скриптов и прочих человеческих факторов. Только GUI, собранной на билд сервере.
Я бы начал с continious deploy поверх всех копий баз основных релизов с последующим прогоном тестов. В результате на QA на порядок меньше работы приходится.
ОК>>Видел, но, опять-таки, в случае такого дизайна, искать нужно по имени таблицы без года. По-моему это очевидно.
F> Ну где же ваша фантазия! Стоит только оставить общий префикс для динамических таблиц с нормальными, первым параметром — имя сущности, вторым — вид анализа — и воля — имя таблицы неотличимо от таблицы ядра.
Какая фантазия? ТС нафантазировал уже. Поэтому я его и спросил о реальных случаях. Теперь ты мне снова предлагаешь проявить фантазию! И я тебя снова спрошу. Ты в реальном коде встречал такое или фантазируешь опять тут только?
А так, нафантазировать и я могу. Радикальный пример я привел выше и повторю его специально для тебя:
