Рекомендации по непрерывной интеграции с проектом SQL Server или локальным файлом mdf в проекте

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

Я знаю, что я мог бы добавить проект SQL Server Database, который содержит только сценарии базы данных и создает файл .dacpac, который позволяет мне автоматически менять базы данных клиентов.

Также я знаю, что я мог бы просто добавить файл .mdf в папку App_Data или даже в Solution_Data и иметь там свою базу данных. Я полагаю, что localDb, который уже существует, позволяет мне запускать мое решение без SQL Server

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

Мои цели:

Автоматически создавать сценарии миграции для клиентов DB.
Сделайте мое решение самодостаточным, чтобы любой новый программист, пришедший на проект, даже не требовал установки SQL Server на своей машине.
Уметь обновлять локальную (разработку) базу за 1-2 клика.
Уметь вернуться в историю изменений в db (у меня есть сервер TFS)
Уметь иметь чистый (только со словарями или поисковыми таблицами) db в решении с современной схемой БД.
Кроме того, я хочу иметь возможность обновлять мою модель БД ( EF или .dbml) автоматически или очень просто.

Так что я, что спросить:

Какие сильные и слабые стороны использования этих двух подходов, если я хочу достичь своих целей?
Может быть, я должен использовать комбинацию этих инструментов?
Или я не знаю о другом существующем инструменте от MS?
Есть ли способ обновить мою модель DAL из этой БД?

Ответ 1

Какие сильные и слабые стороны использования этих двух подходов, если я хочу достичь своих целей?

Использование проекта базы данных позволяет вам управлять версиями всех объектов базы данных. Вы можете публиковать данные в разных экземплярах базы данных и постепенно изменять их, вместо того, чтобы отказываться и воссоздавать базу данных, тем самым сохраняя данные. Эти изменения могут быть в форме dacpac, SQL script или выполняться прямо через интерфейс VS. Вы получаете большой контроль над развертываниями с использованием сценариев до и после развертывания и публикации профилей. Разработчикам потребуется установить SQL Server (версия для разработчиков/экспресс обычно достаточно хороша).

LocalDB немного легче работать - вы можете делать свои изменения непосредственно в базе данных без публикации. LocalDB не имеет встроенного процесса публикации для изменения изменений в других экземплярах. Установка SQL Server не требуется.

Используйте проект базы данных, если вам нужен контроль версий для ваших объектов базы данных, если несколько пользователей одновременно вносят изменения или если у вас несколько приложений, которые используют одну и ту же базу данных. Используйте LocalDB, если ни одно из этих условий не применяется, или для небольших приложений, для которых требуется отдельная автономная база данных.

Может быть, я должен использовать комбинацию этих инструментов?

Да. Согласно комментарию Кевина ниже: "Если проект базы данных задан в качестве вашего проекта запуска, нажатие F5 автоматически разворачивает его в LocalDB. В этом случае вам даже не нужен профиль публикации."

Или я не знаю о другом существующем инструменте от MS?

Подход к интерфейсу Entity Framework First приближается.

Есть ли способ обновить мою модель DAL из этой БД?

Генератор POCO Framework Entity Framework работает хорошо, если вы не вносите изменения в свои классы DAL, тогда эти изменения теряются при следующем запуске генератора.

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

Ответ 2

Одним из способов генерации клиента script для изменений БД является использование инструмента моделирования базы данных, такого как ERWin. У них есть бесплатная версия сообщества. Лучший способ удовлетворить требования к управлению версиями базы данных и простое создание script Redgate SQL Source Control. Используя инструмент Redgate, вы встретите первые пять упомянутых целей. Кроме того, теперь вы можете обновить EF-модель одним щелчком мыши после изменения схемы БД (т.е. Первого подхода к базе данных), как требуется в цели 6.

Я не рекомендую использовать LocalDB вообще. Он всегда создает проблемы с контролем источника, например, "Файл DB используется и не может совершать..." Кроме того, у разработчика в проекте не будет общего набора обновленных данных для работы, если разработчик не добавит тестовые данные к базы данных и попросить других получить последнюю версию и перезаписать свою собственную базу данных. Или создать обновление script предыдущим упомянутым инструментом и попросить каждого разработчика запустить его на своем localDB. Лучший способ в вашей ситуации - использовать SQL Server в сети. Мастер-версия, которую используют все разработчики. Поскольку у вас есть контроль над версиями в базе данных с использованием ранее упомянутого инструмента, вы можете откатить любую ошибку с ошибкой на сервере базы данных.

Если вы считаете, что инструмент RedGate является дорогостоящим для бюджета вашего проекта. Второй подход состоит в том, чтобы сгенерировать единый файл SQL из вашей базы данных, который имеет все объекты базы данных, а другие разработчики обновляют SQL файл в исходном контроле за свои изменения. Это можно сделать легко, используя инструмент сравнения схем в visual studio и добавив сгенерированный файл script в SQL в исходном элементе управления. При первом подходе EF DB вам не придется добавлять несколько классов миграции, как в EF Code.