Как лучше всего настроить SQL Server для среды разработки?

Question

Мы небольшая команда, использующая Visual Studio 2008 для разработки и SQL Server 2008 Standard на производственных серверах. Мы создаем новую лабораторию разработки, и мне интересно узнать о версиях / выпусках и конфигурации SQL Server.

Visual Studio 2008 поставляется с лицензией на разработку SQL Server 2005, но поскольку мы ориентируемся только на SQL Server 2008 для производства, я не думаю, что нам следует устанавливать SQL Server 2005 на рабочих станциях разработки, верно? Вы бы предложили пропустить пакет SQL Server 2005 и, возможно, перейти на SQL Server 2008 Developer? Или, может быть, SQL Server 2008 Express?

Или вы бы порекомендовали вообще не устанавливать SQL Server на рабочие станции разработки и выполнять всю разработку на сервере разработки?

Ваши взгляды приветствуются. Спасибо!

Answer 1

Я собираюсь порекомендовать SQL Server 2008 Express, как и многие другие ответы. Однако я сделаю две дополнительные рекомендации:

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

• Добавьте промежуточный сервер, который точно отражает вашу производственную среду.

Answer 2

SQL Server 2008 (одна из серверных редакций) на сервере

Я обнаружил, что он обеспечивает некоторую дисциплину в безопасности SQL Server и т. Д., Потому что вы не работаете в локальном режиме "бог". Тем не менее, я являюсь администратором баз данных, поэтому у меня другие взгляды на разработку баз данных для более ориентированных на клиента разработчиков.

Я также определенно буду использовать одну и ту же версию и пакет обновления. Честно говоря, это безумие.

Edit:

• SQL Express ограничен в некоторых отношениях, например, процессор, память, размер базы данных и т. Д. Если вы пишете запрос, вы хотите убедиться, что он будет запущен в производство на 10 миллионов строк, которые вы не можете поддерживать локально

• Установка SQL Server не на стороне сервера может быть очень дешевой, в зависимости от модели лицензирования. Преимущество редакции для разработчиков в том, что она может работать на клиентских ОС: я изменил первую строку.

Answer 3

Поскольку ваш рабочий сервер работает под управлением Standard Edition, я бы выбрал Sql Server Express на локальных машинах. Причиной, по которой я предпочел бы это, по сравнению с Developer, является то, что редакция Developer имеет те же функциональные возможности, что и редакция Enterprise, и поэтому было бы легко создать что-то в лаборатории разработки, которую вы внезапно обнаружите, что не сможете развернуть, поскольку эта функция была вырезана из Standard.

Тогда у меня также были бы промежуточные серверы со стандартом Sql Server Standard, который будет максимально соответствовать вашим рабочим серверам.

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Хорошо, если схема никогда не изменяется или если разработчики никогда не несут ответственности за изменение схемы, тогда, возможно, будет работать центральный сервер. При условии, что они не нарушат содержание, потому что не совсем правильно поняли это изменение ... не так, как если бы они когда-нибудь захотели откатить базу данных и попробовать что-то еще, не так ли?

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

Answer 8

Какое у вас производство? Экспресс, Предприятие, Стандарт?

Ваш сервер разработки должен быть Express, если производство Express, и Developer, если производство не Express. Идея заключается в том, что между изданиями существуют различия в том, как доступны определенные функции. Например. Вы можете включить сжатие PAGE в процессе разработки и сделать вывод, что проблем с пространством для хранения данных нет, но в производственной версии используется стандартная версия, которая поддерживает , а не сжатие страниц. Или ваши запросы извлекают выгоду из индексированных представлений, но опять-таки производственный процесс запускается стандартной версией, которая не поддерживает его. Или наоборот, ваша разработка тратит время и усилия на оптимизацию запроса на серверах разработки Express, но производство работает под управлением Enterprise и может использовать простое индексированное представление для решения этой проблемы.

Самый большой набор различий между Express и другими версиями. В конечном итоге то, что вам нужно, зависит в основном от типа продукта (ов), который вы разрабатываете, и от того, какие функции вы будете использовать в своем продукте.

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