Какая лучшая установка 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 и т.д., потому что вы не работают в режиме местного «бога». Тем не менее, я являюсь разработчиком DBA, поэтому у меня есть другой подход к разработке БД для более ориентированных на клиента разработчиков.

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

Edit:

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

Ваше имя: Экспресс, Предпринимательство, Стандарт?

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

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

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

Answer 7

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

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

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

Answer 8

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