Рекомендации по непрерывной интеграции с проектом 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.