Как вы загружаете базы данных SQL Server в среду общего хостинга? - PullRequest
5 голосов
/ 29 октября 2008

У нас общая проблема с переносом нашей базы данных разработки SQL 2005 на общие веб-серверы в хостинговых компаниях.

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

Обычно это достигается восстановлением резервной копии. Но поскольку они являются общими SQL-серверами, мы не можем восстановить резервные копии - нам не предоставляется доступ к реальной машине.

Мы могли бы сгенерировать скрипт для создания структуры базы данных, но тогда мы не смогли бы выполнить передачу данных через пункт меню Задачи / Импорт данных, потому что мы могли бы нарушить ограничения внешнего ключа, поскольку таблицы импортируются в порядке конфликтов с базой данных схемы. Кроме того, индексы могут не реплицироваться, если для них задано автоматическое создание.

Таким образом, нам остается грязная операция:

  1. Создание сценария в SQL 2005, который создает базу данных в формате SQL 2000.
  2. Запустите сценарий для создания базы данных SQL 2000 в SQL 2000.
  3. Создание сценария в SQL 2000, который генерирует структуру базы данных БЕЗ индексов и внешних ключей.
  4. Запустите этот скрипт на рабочем сервере. Теперь у вас есть структура базы данных для загрузки данных.
  5. Используйте SQL 2005 для передачи данных на рабочий сервер с помощью Задачи / Импорт данных.
  6. Используйте SQL 2000 для создания сценария, который создает базу данных с индексами и ключами.
  7. Скопируйте команды, которые генерируют только индексы и внешние ключи. Они расположены после команд создания таблицы. Примечание. В SQL 2005 индексы и внешние ключи создаются как единое целое и не могут быть легко разделены.
  8. Запустите этот скрипт в производственной базе данных.

Вуаля! База данных загружена со всеми данными и ключами / ограничениями на месте. Какая грязная и подверженная ошибкам система.

Есть что-то лучше?

Ответы [ 7 ]

4 голосов
/ 29 октября 2008

Скотт Гу написал несколько сообщений на эту тему:

Инструментарий публикации баз данных SQL Server для веб-хостинга

2 голосов
/ 11 марта 2009

Сценарии генерации хороши для создания объектов базы данных, но не для транспортировки информации базы данных. Например, клиентские базы данных, в которых разработчик обязан предварительно заполнить некоторые данные.

Одна из проблем, с которыми я столкнулся, это новые типы MAX в SQL Server 2005+. (nvarchar (max), varchar (max) и т. д.) Конечно, это хуже, когда вы фактически используете Sql Server Express, который не позволяет экспортировать, кроме создания собственных сценариев для создания данных.

Я бы порекомендовал перейти на хостинговую компанию, которая позволяет вам иметь возможность создавать резервные копии файлов FTP и НЕ требует использования собственных сценариев. В этом весь смысл SQL Server, верно? Чтобы предоставить больше инструментов, которые удобнее использовать. Если хостинговая компания заберет это, вы также можете перейти на MySql для упрощения сбора информации.

WebHost4Life является спасателем в этой категории. Они предлагают FTP на сервер базы данных, чтобы загрузить файл резервной копии или файлы MDF и LDF для вложения! Я был так расстроен, когда увидел, что GoDaddy имеет такое же ограничение, о котором вы упоминали. Их инструмент не сказал мне, что это был плохой импорт, и я не мог понять, почему мой сайт возвращался с 500 ошибками.

Еще одно замечание: я не уверен, что считается более безопасным. Я включил внешние подключения в GoDaddy и подключился к Management Studio, и я смог увидеть каждую базу данных на этом сервере! Я не мог получить к ним доступ, но теперь у меня есть эта информация. Двойной удар заключается в том, что GoDaddy требует, чтобы имя пользователя для БД совпадало с именем БД! теперь все, что вам нужно сделать, это спам-пароли против этих сотен БД!

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

1 голос
/ 29 октября 2008

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

Во-первых, если вы рассматриваете сценарии БД как реальные задачи программирования сами по себе, вы можете инкапсулировать беспорядок. Если вы сгенерируете скрипт один раз (используя инструмент базы данных), вы можете отделить аспекты структуры таблицы от аспектов ограничений (ключи, индексы и т. Д.). Точно так же вы можете экспортировать данные один раз, но разделить их на «системные» данные, которые не часто меняются, но необходимы для правильной работы (такие как налоговые или транспортные расходы и т. Д.), «Тестировать» данные, которые легко идентифицировать, и « оперативные данные, которые необходимо переместить из версии БД Старая в версию БД Новая (Заказы прошлой недели).

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

Мне лично нравится иметь структуру каждой таблицы в виде отдельного файла SQL (и это ограничения в виде отдельного файла в отдельном каталоге, а также тестовые данные в одном файле, системные данные в другом и т. Д.). С одной стороны, это означает, что при внесении изменений необходимо затронуть несколько разных файлов, но с другой стороны, это значительно упрощает просмотр степени детализации того, что было изменено: все это прямо в журналах контроля версий. (Я мог бы быть уверен, что многие файлы - это ошибочная стратегия ...)

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

1 голос
/ 29 октября 2008

Я использовал инструменты RedGate Compare для общего хостинга, и он хорошо работает.

1 голос
/ 29 октября 2008

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

0 голосов
/ 13 августа 2012

Ответ для пользователей SQL Server 2008.

У меня была та же проблема, что и у OP, но я использовал SQL Server 2008, и моей компанией общего хостинга является GoDaddy. Вот решение для копирования БД + данных в базу данных GoDaddy ...

В Visual Studio 2010 перейдите в обозреватель серверов (в VS Express, я думаю, это называется обозревателем баз данных). Щелкните правой кнопкой мыши базу данных и выберите «Опубликовать в провайдере» ... откроется мастер публикации баз данных ... перейдите к мастеру и создадите файл xxx.sql на локальном компьютере ...

Откройте SQL Server Management Studio и подключитесь к базе данных GoDaddy (это вы уже должны были создать через панель управления GoDaddy на их веб-сайте) ...

Откройте проводник Windows, найдите файл xxx.sql и дважды щелкните его. Скрипт должен открыться в SSMS. Выполнить скрипт "в соответствующей базе данных" ... вуаля, готово.

0 голосов
/ 15 апреля 2011

Проверьте, предоставляет ли компания webhsoting myLittleBackup Это, безусловно, самое простое решение «установить» БД с сервера разработки на общий sql-сервер

...