Entity first апгрейд боевой базы данных.

Столкнулся с проблемой: если я в Entity добавляю поле, то мне автоматически генерируется код, который сносит таблицу, затем создает ее заново уже с новым набором полей.

Как автоматически сгенерировать код, который бы просто добавлял новые колонки, новые таблиц, не снося мою БД?

Цитата ttiger @ 18.09.13, 07:33

Столкнулся с проблемой: если я в Entity добавляю поле, то мне автоматически генерируется код, который сносит таблицу, затем создает ее заново уже с новым набором полей.

Как автоматически сгенерировать код, который бы просто добавлял новые колонки, новые таблиц, не снося мою БД?

Все зависит от того какой способ работы с EF используете. Если Model First то апдейты вносите sql скриптами, и работаете всегда с актуальной базой. Если Code First там посложнее. Почитайте об миграциях. Там тоже нет ничего сложного главное чтобы была всегда актуальная база с которой делать разницу.

P.S. Уточните какую БД используете. Так как например с некоторыми типами БД есть сложности.

Сообщение отредактировано: Craft - 18.09.13, 11:42

Цитата Craft @ 18.09.13, 11:39

Если Model First то апдейты вносите sql скриптами, и работаете всегда с актуальной базой.

Model first. При добавлении колонки к таблице сгенерированный скрипт сносит таблицу, генерит таблицу по новой((( Данные теряются.

Цитата Craft @ 18.09.13, 11:39

P.S. Уточните какую БД используете. Так как например с некоторыми типами БД есть сложности.

MS SQL, версию не помню точно выше 2000

Цитата Craft @ 18.09.13, 11:39

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

Вы имеете ввиду сделать разницу средствами БД между боевой базой и той, в которую генерит EF?

Цитата ttiger @ 18.09.13, 12:13

Model first. При добавлении колонки к таблице сгенерированный скрипт сносит таблицу, генерит таблицу по новой((( Данные теряются.

Вы с Model first генерируете код который изменяет БД? Зачем? Мы всегда делали по такому принципу. Заходиш в edmx файл, и нажимаешь Update Model from Database. Скрипты по обновлению БД вносяться отдельно. В скрипте прописываете строки ALTER TABLE ... и т.д.Когда в работаете через Model first то ваша модель не должна генерировать код по созданию БД. А просто отображать мапинг БД в код. Иначе будете перезатирать часто свою модель. Для того чтобы добавлять новые поля и данные в БД сохранялись нужно использовать миграции, так как по дефолту таблици перезатираються. Есть такая трабла в EF.

Цитата ttiger @ 18.09.13, 12:13

Вы имеете ввиду сделать разницу средствами БД между боевой базой и той, в которую генерит EF?

Такая разница должна быть иначе когда вы запустите механизм миграции через NuGet Package то он предположит что нужно пересоздать всю БД и сгенерирует скрипт для создания новой БД. (Используеться в случае Code First - генерация через код)

Сообщение отредактировано: Craft - 18.09.13, 13:22

Цитата Craft @ 18.09.13, 13:22

Вы с Model first генерируете код который изменяет БД? Зачем? Мы всегда делали по такому принципу. Заходиш в edmx файл, и нажимаешь Update Model from Database. Скрипты по обновлению БД вносяться отдельно. В скрипте прописываете строки ALTER TABLE ... и т.д.Когда в работаете через Model first то ваша модель не должна генерировать код по созданию БД. А просто отображать мапинг БД в код. Иначе будете перезатирать часто свою модель.

Зачем? Попробовал в учебных целях накидать учетную систему - столкнулся с траблой
Слава богу, что это не на работе такое

Цитата Craft @ 18.09.13, 13:22

Используеться в случае Code First - генерация через код

В в промышленном коде используете Code First?

Из нее схему БД можно получить?

Цитата ttiger @ 20.09.13, 06:05

В в промышленном коде используете Code First?

Из нее схему БД можно получить?

Да используем. Для удобстра работы использую http://visualstudiogallery.msdn.microsoft....f2-846072eff19d. Если есть готовая база то EF5 версии сделает EDMX модель сразу через Code First. В случае необходимости пересоздать базу. (Если создаем через ADO.NET Entity Data Model). При конфигурации БД пишем чтобы база создавалась только если не существует. Обновление проходит через DBMigration. Создать вручную EDMX файл, для того чтобы увидеть можеть можно вот так Create edmx file. Но проще всего если вы добавляли новые классы в базу руками через CF, то запускаем Package Manager Console, затем создаем БД через этот Package Manager, после этого в студии делаем схему БД. Вы под схемой же имели ввиду визуально представление таблиц и связей?

Цитата Craft @ 20.09.13, 09:40

Да используем. Для удобстра работы использую http://visualstudiogallery.msdn.microsoft....f2-846072eff19d.

Уже понравилась эта штука после описании фичи
"Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database."

Добавлено 20.09.13, 09:45

Цитата Craft @ 20.09.13, 09:40

ы под схемой же имели ввиду визуально представление таблиц и связей?

Да, его. С ним жить лучше, чем без него

ttiger, по моему опыту нет такого нормального инструмента, который бы сгенерировал разницу между двумя БД. Тут дело еще вот в чем.. Инкрементное изменение БД это чаще всего не просто изменение схемы, но еще и изменение данных. Например:

1. Добавление простой колонки NOT NULL требует указать значение для нее по умолчанию. Но допустим, что у нее не должно быть значения по умолчанию. Ведь тогда ее можно нечаянно пропустить в запросе INSERT. Тогда после добавления колонки, когда она в первый раз заполнится, надо удалить из нее информацию о значении по умолчанию.

2. Переименование колонки в проекте обычно приводит к удалению колонки на сервере и добавлению новой. Инструмент генерации инкрементного скрипта просто не поймет что ее переименовали. А значит ее данные будут потеряны.

3. Добавляешь новую колонку с внешним ключом на новую таблицу. Надо создать новую таблицу. Добавить в нее хоть одну запись по умолчанию. Создать в существующей таблице колонку со значением внешнего ключа по умолчанию. Удалить из схемы значение по умолчанию. Получается, что в инкрементный скрипт кроме DDL операторов надо добавить и DML операторы. Причем в определенном (иногда не тривиальном) порядке.

Есть конечно инструменты, которые генерируют инкрементный DDL скрипт, который меняет схему БД. Например, если у тебя вижуал студия ultimate, то в ней есть проект БД, и инструмент в меню Database Schema Comparision. Он делает как раз именно это. Но кроме DDL операторов, такой скрипт почти всегда обязан содержать DML операторы, причем в определенной последовательности. А вот этого такие инструменты не умеют По крайней мере, я не слышал.

4. Бывает ситуация еще хуже. Чтобы накатить такие изменения на боевую БД, обычно надо остановить сервер приложений, чтобы ничего не поломалось. Но скрипт обновления огромной БД из-за DML операторов может занять много времени, час или полтора. Тогда такой скрипт вручную делят на два. Один изменяет схему БД и трансформирует существующие данные по минимуму. Чтобы например новые записи в БД писались нормально. А потом уже после старта сервера в фоновом режиме запускают скрипт трансформации старых данных. Никакой инструмент таких сложностей не учтет.

По опыту, в проекте БД паралельно скриптам с актуальном схемой БД, поддерживают в идеальном порядке историю инкрементальных БД, которые организуются в патчи, которые можно накатить на любую версию БД, чтобы обновить ее. Жесткий контроль, тесты и кодеревью, помогают держать актуальную схему и список инкрементов в синхронизированном состоянии.