MS SQL data export/import

Sabina · Post by **Sabina** » 17 Feb 2004 19:35

Возвращаясь к этому вопросу...

Если нужно воссоздать точную копию существующей базы из текст файлов, можно ли сделать так:

1) прогнать скрипт, создающий все таблицы;
2) импортировать данные ( в том числе lookup data)
3) посадить на это constraints (FK, etc.) ?

Если таблицы создать сразу с constraints, то импортировать всю базу одним махом соответственно не получиться. Хочу сделать так как описано выше, но не уверена, что при таком раскладе нет каких-нибудь подводных камней.

Сабина

Sabina · Post by **Sabina** » 18 Feb 2004 22:07

Еще раз извиняюсь за возврат к этой теме, но мне ОЧЕНЬ нужна помощь с этим вопросом.
В Интернете я ничего толкового найти не могу, ибо большинство народу пользуется import/export тулами и там рассматривается в основном какую кнопку нажать, какую опцию включить, нежели концептуальная сторона вопроса.

У меня есть скрипты, которые создают всю базу from scratch. То есть как создать чистую базу с нуля - понятно.
А как создать копию уже существующей базы с данными?

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

Мой вопрос так ли оно обычно делается, или нет?

Спасибо,
Сабина

tengiz · Post by **tengiz** » 18 Feb 2004 23:05

Sabina wrote:А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

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

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

Sabina · Post by **Sabina** » 19 Feb 2004 01:21

tengiz wrote:
Sabina wrote:А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

dbschema меняется (таблицы добавлены), а данные надо оставить.

irksome · Post by **irksome** » 19 Feb 2004 05:49

Sabina wrote:
tengiz wrote:
Sabina wrote:А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

dbschema меняется (таблицы добавлены), а данные надо оставить.

А нельзя новые таблицы создать в новой копии?

Sabina · Post by **Sabina** » 19 Feb 2004 06:24

irksome wrote:
Sabina wrote:
tengiz wrote:
Sabina wrote:А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

dbschema меняется (таблицы добавлены), а данные надо оставить.

А нельзя новые таблицы создать в новой копии?

Пока так и делаем, но для этого надо кому-то собирать все changes в отдельный update script и ранать. Они хотят чтобы я им написала нечто, чтобы нажал на кнопку и готово.
Я в приниципе написала по тому принципу что выше описала, сейчас буду тестировать. НО мне это все жутко не нравится. Хочется узнать как жругие это делают.

Неужели все делают backup/restore и потом изменеия добавляют? Или никто не делает DBSchema changes после того как в базе уже есть данные :pain1:

?

Сабина

tengiz · Post by **tengiz** » 19 Feb 2004 06:50

Sabina wrote:Неужели все делают backup/restore и потом изменеия добавляют? Или никто не делает DBSchema changes после того как в базе уже есть данные

Самое лучшее, что можно сделать, это не создавать объекты в базе "по-живому", а изменять мастер-скрипты, создающие базу, объекты в базе и заливающие данные. Для чего девелоперы должны чётко осознавать, что если они нарушат эту процедуру (все изменения только в скриптах), то при следующей итерации они всё что наработали "на живую" элементарно потеряют. Такая технология имеет много преимуществ, которые уже давно не нуждаются в обосновании, и под такую манеру работы есть масса стандартных инструментов.

Другой вариант - reverse engineering, который умеют делать страндартные database design инструменты. Однако в мои времена они всего лишь были удобным подспорьем, и ни в коем случае не могли служить полноценной заменой того, что изложено выше.

Так что на мой скромный взгляд, самая большая проблема здесь - это организация эффективного процесса разработки, а не экспорт/импорт. Я бы именно в этом направлении двигался.

Dmitry67 · Post by **Dmitry67** » 19 Feb 2004 09:17

Sabina, я наконец понял что у Вас хотят

У нас при разработке делают так
Все изменения sp при релизе отливают просто скопом
А вот изменения структуры делаются скриптами
Я потом эти скрипты собираю, тестирую и формирую скрипт для PREPROD -> PROD

Вы хотите реинжениринг, по старой и новой схеме сгенерить alter tables. Такой тул у меня есть

но это очень нетривиально

Задайте своему шефу вопросы
Что делать если колонке в таблице убрали NULL
Что делать если уменшьшили длину verchar - is it ok to truncate data ?
Что делать если таблитцу или колонку переименовали - догадаться ? Или это новые объекты ?

Sabina · Post by **Sabina** » 19 Feb 2004 19:04

Dmitry67 wrote:Sabina, я наконец понял что у Вас хотят?

Да, я наверное не очень понятно изъясняюсь, поскольку имею с этим делом в первый раз. Сорри.

Dmitry67 wrote:У нас при разработке делают так
Все изменения sp при релизе отливают просто скопом
А вот изменения структуры делаются скриптами
Я потом эти скрипты собираю, тестирую и формирую скрипт для PREPROD -> PROD

У нас тоже до прошлой недели изменения структуры делались upgrade скриптами и составляла их одна strong backend programmer, которая на этой неделе ушла.
То есть она собирала все изменения из master scripts и потом вставляла это все в batch и передавала QA, чтобы они это прогнали на своих серверах.
Теперь эта дама ушла, а я работаю из дома. Доступа к QA серверам у меня нет, поскольку если что пойдет не так... Короче я это на себя взять не могу.
QA считает, что если я сделаю им скрипт, который импортирует данные во вновь созданную базу (по обновленным master скриптам), то это будет решением вопроса. Но я чем больше работаю над этим делом, тем меньше верю в надежность такого выхода.

Dmitry67 wrote:Вы хотите реинжениринг, по старой и новой схеме сгенерить alter tables. Такой тул у меня есть но это очень нетривиально

Можно название тула, просто так чтобы знать? У нас не так много изменений, чтобы пользоваться тулом, все можно и в ручную. В крайнем случае я могу писать скрипты, QA их прогонять. Ну и если что не так - поеду в офис за 30 миль

Dmitry67 wrote:Задайте своему шефу вопросы
Что делать если колонке в таблице убрали NULL
Что делать если уменшьшили длину verchar - is it ok to truncate data ?
Что делать если таблитцу или колонку переименовали - догадаться ? Или это новые объекты ?

Мой шеф врядли ответит на этот вопрос

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

Опять же для меня самой чтобы знать, а как вы выходите из ситуации, когда колонка вдруг стала not null, или длину колонки урезали, колонку переименовали? Можно просто ткнуть в URL не объясняя здесь подробно.

Спасибо,
Сабина

SkyWalker · Post by **SkyWalker** » 19 Feb 2004 19:28

Есть несколько вариантов решения.

1. Организационное.
Девелоперы при изменении чего либо готовят script. Если ето изменение структуры таблицы то соответственно script с ALTER и т.д.
Данные скрипты отправляются DBA. DBA готовит upgrade script затем тестирует на тестовой базе и затем делает upgrade боевой базы.
Tаким образом вы будете иметь upgrade script для каждой версии базы. К тому же еше неплохо писать где-нибудь в саму базу номер текушей версии. Ето опять же можно добавлять в upgrade script.

2. Автоматическое.
http://www.adeptsql.com/
http://www.lockwoodtech.com/index_sqldiff.htm
http://www.red-gate.com/sql_comparison_ ... oolkit.htm

и т.д. Таких tool'oв очень много. Но в етом случае Вы не будете контролировать ситуацию, да и работу каждого из них надо сначала хорошенько проверить

3. Интересное

Написать синхронизацию самому, использовать скриптование и т.д.
Процесс давольно трудоемкий и не во всех случаях простой. Синхронизацию SP, view, UDF можно реализовать достаточно не сложно, а вот изменение структуры таблиц, триггеров, добавление FK, PK, index и т.д. может вызвать сложности.

Dmitry67 · Post by **Dmitry67** » 19 Feb 2004 19:51

SkyWalker wrote:3. Интересное
Написать синхронизацию самому, использовать скриптование и т.д.
Процесс давольно трудоемкий и не во всех случаях простой. Синхронизацию SP, view, UDF можно реализовать достаточно не сложно, а вот изменение структуры таблиц, триггеров, добавление FK, PK, index и т.д. может вызвать сложности.

Я такое написал
Не могу не похвастаться
Самое сложное это когда и таблицу переименовали догадаться что это старый объект
А если в ней еще и колонкдновремено перимеовали то совсем сложно
Но я с этим справился

Sabina · Post by **Sabina** » 19 Feb 2004 20:23

Dmitry67 wrote:Я такое написал
Не могу не похвастаться

Напишите хоть на чем писали :wink:

. Чисто Transact-SQL или еще что?

Сабина

Dmitry67 · Post by **Dmitry67** » 19 Feb 2004 20:26

на Perl

Могу завтра прислать EXE в подарок

PS
В копилку - недавна присали классную процедуру
sp_generate_inserts, не используете ?

Sabina · Post by **Sabina** » 19 Feb 2004 20:40

Dmitry67 wrote:на Perl
Могу завтра прислать EXE в подарок

Буду премного благодарна. Я как раз Perl изучаю :wink:

В смысле по тому что ваш экзешник делает, буду представлять, как это написать на перле :mrgreen:

Сабина

Dmitry67 · Post by **Dmitry67** » 19 Feb 2004 20:44

Тогда киньте приватом мне почту куда посылать

Sabina · Post by **Sabina** » 21 Feb 2004 07:39

Дим, а почему там написано
"Do you hate ERWIN ? You're in the right place"

?

Dmitry67 · Post by **Dmitry67** » 21 Feb 2004 10:05

Потому что я ненавижу ERWIN

И вообще программы которые себя считают умнее человека
Особенно меня потряс случай когда ERWIN попытался молчаливо снести важные колонки которые посчитал 'ненужными'

irksome · Post by **irksome** » 21 Feb 2004 17:14

Dmitry67 wrote:Потому что я ненавижу ERWIN

А чем пользуетесь для моделирования базы?

Dmitry67 · Post by **Dmitry67** » 21 Feb 2004 23:25

Я ее так представляю и помню
Предпочитаю скрипты

Вообще это странно
Современные эе программисты не пишут блок схем
Но почемуто считается что в области баз надо обязательно рисоваь картинки

tengiz · Post by **tengiz** » 22 Feb 2004 02:38

Dmitry67 wrote:Вообще это странно. Современные эе программисты не пишут блок схем. Но почемуто считается что в области баз надо обязательно рисоваь картинки

Exactly. Наверное, модели данных рисуют те, кто и для написания программ (даже несложных) использовали бы блок-схемы. Т.е. сами знаете кто.

irksome · Post by **irksome** » 22 Feb 2004 03:10

tengiz wrote:
Dmitry67 wrote:Вообще это странно. Современные эе программисты не пишут блок схем. Но почемуто считается что в области баз надо обязательно рисоваь картинки

Exactly. Наверное, модели данных рисуют те, кто и для написания программ (даже несложных) использовали бы блок-схемы. Т.е. сами знаете кто.

А мне кажется, что рисование модели ничего плохого о рисуещем как о проектировщике не говорит :-)

Тем более, что в общем случае он общается с людьми разного уровня от начальства, пользователей до ДБА и модели один из способов общения.

Sabina · Post by **Sabina** » 22 Feb 2004 06:19

Dmitry67 wrote:Sabina, я наконец понял что у Вас хотят
Вы хотите реинжениринг, по старой и новой схеме сгенерить alter tables.

Рассказала я про ваш замечательный тул нашей strong backend programmer (которая ушла, но мы с ней как бы переписываемся), а она все равно настаивает на том, что тот скрипт, который мне дали писать нужен:

the purpose of the import/export is to be able to upload old data into a new schema.
Indudably, if the schema has changed in ways that some column data cannot
be loaded, you customize the differences as an upgrade, which is the usual procedure for schema upgrades, but the script should be able to load the data that has not changed.

короче,
Сабина

f_evgeny · Post by **f_evgeny** » 22 Feb 2004 08:36

tengiz wrote:
Dmitry67 wrote:Вообще это странно. Современные эе программисты не пишут блок схем. Но почемуто считается что в области баз надо обязательно рисоваь картинки

Exactly. Наверное, модели данных рисуют те, кто и для написания программ (даже несложных) использовали бы блок-схемы. Т.е. сами знаете кто.

А я рисую

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

tengiz · Post by **tengiz** » 22 Feb 2004 09:04

f_evgeny wrote:А я рисую

А как же фишечи (или как Вы их там любите называть) в виндовс или как Вы его там называете ?

Vovka · Post by **Vovka** » 22 Feb 2004 09:49

Dmitry67 wrote:Я ее так представляю и помню
Предпочитаю скрипты

Вообще это странно
Современные эе программисты не пишут блок схем
Но почемуто считается что в области баз надо обязательно рисоваь картинки

Забавное наблюдение.
Я вот как раз представляю себе базу данных в виде "картинок" - мне так проще. Но я не датабазник, сталкиваюсь с этим только эпизодически, по необходимости.

А вот в софте действительно не выношу всяких там "диаграмм", "сущностей", и господ системных аналистов, рисующих с одухотворёнными физиономиями картинки в розе. Вообще эту ОО-теорию считаю какой-то диверсией, организованной марсианами. Их земной базой является штаб-квартира Rational, но они уже опутали своими нитями всю Землю, их агенты проникли практически в каждую команду системных архитекторов, и земную ИТ-индустрию ждёт неминуемая смерть, если только нам не удастся вовремя опомниться и освободить себя это этой порочной идеологии. Главной нашей опорой несомненно являются скромные ребята кодеры, такие как я, имунные к убаюкивающим словам вроде "UML", "entity", "object", etc.