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

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

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

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

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

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

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

Редактировать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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