Лучшая практика для заполнения статических данных с помощью Проект базы данных Visual Studio 2010?

Как заполнить базу данных статическими данными с контролем источника с помощью проекта базы данных Visual Studio? Я испробовал все три стратегии, представленные ниже, и обнаружил, что каждая из них становится все лучше предыдущей. Я использую, но не полностью удовлетворен стратегией 3 . У вас есть другая альтернатива?

1. Поместите скрипты вставки в папку «Планы создания данных».Ссылайтесь на сценарии в файле «Script.PostDeployment.sql», чтобы включить их в процесс развертывания.

   - преимущество: прямолинейность
   - недостаток: slooooooow
   - недостаток: при последующих развертываниях необходимо сначала удалить статические данные или проверить отсутствие данных => неэффективно

2. Вставьте данные в базу данных в первый раз, используя наиболее удобный метод (например, это может быть функция таблицы редактирования SSMS) . Извлеките эти данные с помощью утилиты командной строки bcp, чтобы создать набор файлов данных и добавить их в свой проект. Создайте сценарий, указанный в файле «Scripts.PostDeployment.sql», который выполняет оператор «массовой вставки» для каждого файла данных.

   - преимущество: намного быстрее, чем операторы вставки
   - преимущество: можно использовать функцию редактирования таблицы SSMS
   - недостаток: для каждого оператора массовой вставки требуется полное имя файла для файла данных, поэтому, если файлы данных находятся на моем компьютере в "C: \ Projects \ Dev \ Source \ foo.dat", то удаленный компьютер разработчика также должен разместите их в этом месте, или оператор массовой вставки не сработает
   - недостаток: необходимо удалить существующие статические данные перед выполнением операторов массовой вставки при последующих развертываниях

3. Создавайте временные таблицы во время развертывания для хранения статических данных и используйте оператор слияния sql для синхронизации этих таблиц с целевыми таблицами. См. или из эти сообщения в блоге.

   - преимущество: похоже, что слияние sql имеет идеальную семантику для решения проблемы
   - недостаток: логика этой стратегии повторяется в каждом файле - недостаток: определения таблиц повторяются как временные таблицы в файлах слияния sql

Есть ли лучшая альтернативная стратегия? Я отказался от стратегии 1, потому что она была слишком медленной. Мне не нравится стратегия 2 из-за проблемы с полным именем файла. Я удовлетворен, но не в восторге от стратегии 3. Есть ли лучший способ?