Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10   вперед  Ctrl      все
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
GuestGuestGuest
И еще: может выскажется кто с конкретными доводами, почему необходимо и, наоборот, почему ни в коем случае не стоит добавлять разработчиков в группу sysadmin на сервере/инстансе для разработчиков.

У нас такого сервера нет. У разработчиков у каждого стоит свой инстанс. Сборка сетапа вообще через скрипты происходит, никаких "общих серверов". Общее - это SourceSafe, где эти скрипты хранятся. Для тестирования поднимаются потребные энвайроменты со всеми необходимыми наворотами в любой конфигурации, к ним разработчики опять же не имеют отношения.
13 янв 06, 18:49    [2253893]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
То 0.Это вопрос в чем то идеологический.Ну например как о существовании группы батлин сисадмин, по умолчанию. Существует много мнений на эту тему. Лично когда в одну из компаний в котрой я сопровождал ИТ систему приходили аудиторы(из одной автритетной компании) то мне пришлось с ними поспорить на эту тему(потому как у меня на эту группу как раз стояла ловушка.)
А в целом нужно у всех урезать права по максимуму. Их как правило проще выдать.
14 янв 06, 06:57    [2254647]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
Тогда сформулируем вопрос иначе:
1. Какие минусы от того, что разработчики БД не включены в группу sysadmin и как эти минусы нивелировать, не включая их в группу sysadmin?
2. Какие риски для проекта, компании, и т.п. могут возникнуть, если разработчики БД включены в группу sysadmin и как эти риски минимизировать, оставив при этом разработчиков в группе sysadmin?
3. Хоть это и не в тему данного форума, но все же: как лучше организовать коллективную работу для разработки приложений на платформе MS SQL Server?
Компания небольшая, одновременно разрабатываются и сопровождаются несколько проектов разной сложности. Один разработчик может работать над несколькими проектами. Все разработки ведутся на одном физическом сервере, на разных базах или инстансах. Для каждого проекта кроме версии для разработки есть еще эталонная (продакшн?) версия, на которую накатываются изменения. С некоторых пор права разработчиков решили понизить до db_owner со всеми вытекающими проблемами. Отсюда и вопросы.
14 янв 06, 13:12    [2254831]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
aleks2
Guest
GuestGuestGuest
Тогда сформулируем вопрос иначе:
1. Какие минусы от того, что разработчики БД не включены в группу sysadmin и как эти минусы нивелировать, не включая их в группу sysadmin?
2. Какие риски для проекта, компании, и т.п. могут возникнуть, если разработчики БД включены в группу sysadmin и как эти риски минимизировать, оставив при этом разработчиков в группе sysadmin?
3. Хоть это и не в тему данного форума, но все же: как лучше организовать коллективную работу для разработки приложений на платформе MS SQL Server?
Компания небольшая, одновременно разрабатываются и сопровождаются несколько проектов разной сложности. Один разработчик может работать над несколькими проектами. Все разработки ведутся на одном физическом сервере, на разных базах или инстансах. Для каждого проекта кроме версии для разработки есть еще эталонная (продакшн?) версия, на которую накатываются изменения. С некоторых пор права разработчиков решили понизить до db_owner со всеми вытекающими проблемами. Отсюда и вопросы.


1. Один минус - настройки сервера разработчик поменять не сможет, нужно будет бежать к sysadmin. Это же является плюсом, поскольку не надо выяснять кто подкрутил и почему сегодня работает не так как вчера.

2. Абсолютно неконтролируемое изменение всего и вся в базах сервера, без всякой возможности установить кто персонально это сделал. Здесь НИЧЕГО нельзя изменить - как ни крутись.

3. Здесь нет принципиальных отличий от коллективной разработки на любой другой платформе.
14 янв 06, 13:28    [2254851]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
aleks2

1. Один минус - настройки сервера разработчик поменять не сможет, нужно будет бежать к sysadmin. Это же является плюсом, поскольку не надо выяснять кто подкрутил и почему сегодня работает не так как вчера.

2. Абсолютно неконтролируемое изменение всего и вся в базах сервера, без всякой возможности установить кто персонально это сделал. Здесь НИЧЕГО нельзя изменить - как ни крутись.


Так что же, лучше ничего не менять, если изменения нельзя контролировать?
Не возрастут ли риски невыполнения проекта в срок, если надо изменения синхронизировать централизованно (в пятницу после-обеда, например) и следующий этап можно начинать только после наката обновлений? И не будет ли бедный sysadmin заниматься только накатом/откатом обновлений, а разработчики в это время будут стоять в очереди и ждать, когда обновление будет внесено. И на чем, собственно, они должны заниматься разработкой? На отдельной локальной базе? Как Вы контролируете изменения, вносимые членами группы db_owner для каждой базы?
14 янв 06, 13:44    [2254868]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
GuestGuestGuest
Так что же, лучше ничего не менять, если изменения нельзя контролировать?
Не возрастут ли риски невыполнения проекта в срок, если надо изменения синхронизировать централизованно (в пятницу после-обеда, например) и следующий этап можно начинать только после наката обновлений? И не будет ли бедный sysadmin заниматься только накатом/откатом обновлений, а разработчики в это время будут стоять в очереди и ждать, когда обновление будет внесено. И на чем, собственно, они должны заниматься разработкой? На отдельной локальной базе? Как Вы контролируете изменения, вносимые членами группы db_owner для каждой базы?

Да поймите вы, нельзя не только разработчиков пускать в живую базу, им нужно выдать каждому по отдельному серверу (ну или хотя бы инстансу).
Большую часть задач можно решить, поставив каждому просто MSDE.
Есть масса случаев, когда разработчик просто ОБЯЗАН, например, загрузить сервер по самые помидоры. Что юзеры делать будут, когда программер тестирует быстродействие и дедлоки, беспрерывно орбращаясь к серверу с десятка запущенных программ? Прорываться через тайм-ауты? А если дедлок все-таки возникнет?
Потом, разработка живого проекта подразумевает внесение изменений в СУЩЕСТВУЮЩИЕ таблицы. Что делать клиенту, который очень хочет прочитать поле, которое по замыслу разработчика уже никому не нужно, но он об этом еще никому не сказал? Что если он грохнул пару таблиц, а потом передумал? Поднимать бэкап? Так за это время 20 пользователей успели внести некоторое к-во данных.
Результатом работы программера, как тут уже неоднократно говорилось должен быть скрипт, который уже реальный сисадмин, незнающий начего об операторах SELECT, INSERT, WHILE накатывает на базу.

У нас организовано так: программеры пишут, используя каждый СВОЙ сервер, свои части. Если необходимо, лезем ненадолго друг к другу. Единственное, что нам приходится синхронизировать (голосом :) ) - версию очередного скрипта. Новые скрипты синхронизируются через TeanSource. Параллельно все скрипты выкладываются на ФТП, откуда их забирают уже настоящие админы баз (у нас больше 20 установок по Москве и области). Туда же выкладываются свежие exe-шники. Вся задача админа - запустить нужные ему скрипты в правильной последовательности и залить на сервер exe. Хотя и это уже автоматизировано - админу нужно просто переписать все с ФТП, а спец. программка сама определяет, какие скрипты и в каком порядке запускать, какие программы на сервер закачивать. Да еще и бэкап делает и рестор, если скрипты сглючили. Красота! :) У нас уже не болит голова, когда можно вносить изменения, а когда - работы у пользователей слишком много и им лучше потерпеть старую версию, чем быть битыми недовольными клиентами. ;)
А все глюки в базе, на которой один программер занимался еще и разработкой, до сих пор выгнать не смогли.

Насчет времени сдачи проекта и накатов/откатов:
Пункт № 1. проект должен быть сдан.
Пункт № 2. проект должен быть сдан вовремя.
Пункт № 3. если проект сдан вовремя, но не работает, он сданным не считается вообще.

Откатов у sysadmina быть не должно:
юзеров выгнал,
базу забэкапил,
скрипты накатил,
если глюк в скриптах - наорал на программеров, восстановил бэкап,
запустил юзеров.

А уж программеры сами ОБЯЗАНЫ тестировать скрипты на выполнимость их на "эталонной(их) базе".
Если же на одной из баз скрипт невыполнился из-за отличия его от эталонной, то программер пишет эксклюзивный скрипт для приведения "кривой" базы к эталону.
Если скрипт вополнен нормально, но программер, например, ошибся в тексте триггера, то он пишет ЕЩЕ ОДИН, который правит изменения в старом триггере.
Такая схема отнимает процентов 10-20 времени на разработку, но экономится 100% времени затрачиваемого на ликвидацию глюков в живой базе. Это дорогого стоит.

А db_owner на то Владелец, чтобы быть в единственном числе. :)
14 янв 06, 14:32    [2254930]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Этот вопрос не раз уже поднимался на форуме, воспользуйтесь поиском.

И еще раз задумайтесь о том, что результаты работы программистов могут храниться не только в базе, куда каждый (или не каждый) лезет ручками, а в системах контроля версий. Как раз для второго варианта отсутствуют минусы беготни к сисадмину, минусы выяснения кто виноват (все же логгируется автоматически), упрощается сборка версий и формирование пакета изменений между той или иной версией.
14 янв 06, 14:48    [2254954]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
DeColo®es, поддерживаю.
14 янв 06, 15:03    [2254966]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
[quot DeColo®es]Большую часть задач можно решить, поставив каждому просто MSDE.
Есть масса случаев, когда разработчик просто ОБЯЗАН, например, загрузить сервер по самые помидоры. Что юзеры делать будут, когда программер тестирует быстродействие и дедлоки, беспрерывно орбращаясь к серверу с десятка запущенных программ? Прорываться через тайм-ауты? А если дедлок все-таки возникнет?[quot]
В живой базе разработчиков нет, она вообще стоит у заказчиков и обновляется скриптами (если проект только сопровождается). Для новых проектов только эталонная база (там только тестовые данные, аккумулируются все изменения и которую мучают тестеры). Вопрос в том, может ли разработчик БД полноценно проводить разработку имея ограниченные права? Если разработка проводится на единственном общем сервере для разработчиков, то к чему приведет исключение разработчиков из группы sysadmin (для конкретного SQL сервера или инстанса) и, соответственно, включение их в ту группу? Насколько эти мероприятия могут повлиять на безопасность сервера и целостность проекта?
14 янв 06, 15:16    [2254984]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Гы. Безнадежный разговор...
14 янв 06, 15:27    [2255001]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
GreenSunrise
Гы. Безнадежный разговор...

Почему?
14 янв 06, 15:37    [2255017]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
GuestGuestGuest
GreenSunrise
Гы. Безнадежный разговор...

Почему?

Потому, что разработка БД на одном общем сервере - порочна изначальна?
14 янв 06, 15:39    [2255018]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Потому что вы то ли не читаете ответы, то ли игнорируете их, после чего в десятый раз задаете один и тот же вопрос. В результате разговор не клеится.
14 янв 06, 15:43    [2255023]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
GreenSunrise
Потому что вы то ли не читаете ответы, то ли игнорируете их, после чего в десятый раз задаете один и тот же вопрос. В результате разговор не клеится.

Очень внимательно читаю ответы, но для меня важен ответ именно на вопрос:
автор
Вопрос в том, может ли разработчик БД полноценно проводить разработку имея ограниченные права? Если разработка проводится на единственном общем сервере для разработчиков, то к чему приведет исключение разработчиков из группы sysadmin (для конкретного SQL сервера или инстанса) и, соответственно, включение их в ту группу? Насколько эти мероприятия могут повлиять на безопасность сервера и целостность проекта?

Может это и не совсем корректный вопрос, для человека сведующего все должно быть понятно само собой, можно было бы и не спрашивать, но Ваши ответы нам очень важны, что бы принять правильное решение для организации коллективной работы над проектами в нашей компании. Так что хотелось бы услышать побольше мнений, основанных на практическом опыте ведения разработок.
14 янв 06, 15:59    [2255032]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
GreenSunrise
Этот вопрос не раз уже поднимался на форуме, воспользуйтесь поиском.

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

Результатом работы является не только код в системе контроля версий, но и производительность исполнения кода, нагрузка кода на систему, разные там блокировки во время выполнения кода, которые на локальной версии БД могут отличаться от рабочей и увидеть которые не очень помогают понижения прав разработчикам. Некоторые вещи может увидеть только член группы sysadmin. Продолжим?
14 янв 06, 16:09    [2255048]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
С хранением скриптов создания объектов БД в специльных хранилищах с контролем версий (типа Source Safe) согласен, так и делаем. Использование локальных MSDE как вариант для разработчиков - не удобно и ограничено. Отдельный сервер или инстанс для каждого разработчика? Допустим, решили все проблемы с синхронизацией структуры БД и данных в таблицах (на то, что там сотни таблиц и различных объектов и гигабайты тестовых данных внимания пока не обращаем). Выходим на финишную прямую, надо протестировать весь написанный код по полной программе. Рабочую базу не трогаем, мы ее не видим, она стоит у заказчика. У нас только ее прототип, заполненный тестовыми данными, моделирующими процесс деятельность объекта автоматизации. Так какой вред проекту нанесет разработчик, если он станет проводить тесты с правами администратора БД? Что он может не увидеть, если разработчика, проводящего тест написанного им кода, отлучить от прав администратора БД? Если разработчику не давать права администратора БД, то какие можно дать, что бы он с одной стороны не развалил проект, но увидел все, что нужно для правильного понимания выполнения кода, с другой? Вот в чем вопрос! Не надо думать, что у разработчиков рукие чуть более прямые руки чем у пользователей.
14 янв 06, 17:58    [2255153]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
GuestGuestGuest
Результатом работы является не только код в системе контроля версий, но и производительность исполнения кода, нагрузка кода на систему, разные там блокировки во время выполнения кода, которые на локальной версии БД могут отличаться от рабочей и увидеть которые не очень помогают понижения прав разработчикам. Некоторые вещи может увидеть только член группы sysadmin. Продолжим?

По-прежнему не вижу необходимости в ОБЩЕМ сервере. Как это сделано у нас:
1. Разработка ведется отдельно, у каждого на машине свой сиквел. Там каждый сам себе админ.
2. Конечный продукт - в SourceSafe.
3. Тестирование (работоспособность, производительность, блокировки) - ОТДЕЛЬНЫЕ машины. vmware - это вам о чем-то говорит?

Для тестирования составляется тест-план, включающий в себя чертову уйму тестовых требований. Тестовые требования делятся на группы:

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

Стресс-тесты. Они включают в себя описание тестирования самых разных аспектов функционирования системы:

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

- стрессовое количество конкурирующих действий, относящихся к одним и тем же компонентам системы. Локи, дедлоки, да.

- производительность. Тут все понятно.

- секьюрити. Если система предусматривает разграничение прав, тестировать обязательно.

Ну и т.д. На каждый такой тест описано, какую среду устанавливать, какие скрипты запускать, как это все должно взаимодействовать. Когда версия отправляется в тестирование, задачи раздаются тестировщикам. Тестировщик берет тестовое требование, ставит описанную среду на СВОИХ СОБСТВЕННЫХ vmware'ях и гоняет на ней все, что нужно

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

Поскольку среда тестовая, сервера тестовые, он всегда знает пароль администратора и может дать программисту возможность пользоваться любой функциональностью сиквела, которая только может понадобиться для понимания причин багов. Надо тебе трассу? На тебе трассу. Надо тебе на ночь страшный джоб - на тебе джоб. Надо ребилд мастера - да запросто! А что, вы думаете, ребилд мастера никому не нужен? Ха! Тестирование восстановления репликационной группы после сбоя не хотите? И куда я тестера на вашем ОБЩЕМ серваке с такой задачей в тест-плане пошлю? Надо удалить Built-in администраторов с целью тестирования секьюрити - да пожалуйста, мил чел, удаляй сколько влезет. Хочешь сиквел с предустановленной базой в десятки гиг - солнце, вот тебе имидж вмвари, где она есть. Полчаса максимум - и хоть утестируйся. Тестирование поведения продукта с новым сервис-паком для сиквела? Вот тебе отдельная вмварь - тестируй на здоровье.

Не представляю совершенно, как для конторы, где количество разработчиков и тесторов превышает пару-тройку человек, работать на ОБЩЕМ сервере. Это ж убийство!

GuestGuestGuest
Так какой вред проекту нанесет разработчик, если он станет проводить тесты с правами администратора БД?

Запустить страшный тест на одновременный доступ - производительность + дедлоки + нагрузка на сеть + нагрузка на проц. Все нервно курят. Настала жопа. Имхо, это вред продукту.

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

GuestGuestGuest
Что он может не увидеть, если разработчика, проводящего тест написанного им кода, отлучить от прав администратора БД?

Без профайлера временами полная ж. Мне достаточно такого аргумента. Плюс невозможность разработки и тестирования многих фичей, которые требуют админского доступа. Вон та же репликация - подите настройте ее, не входя в sysadmin.

GuestGuestGuest
Если разработчику не давать права администратора БД, то какие можно дать, что бы он с одной стороны не развалил проект, но увидел все, что нужно для правильного понимания выполнения кода, с другой?

Дайте ему ВСЕ!!! Только на его личном серваке. И он ничего не развалит.

GuestGuestGuest
Не надо думать, что у разработчиков рукие чуть более прямые руки чем у пользователей.

Правильно! Поэтому начинай читать сначала. ОТДЕЛЬНАЯ среда. И пусть курочит ее, сколько ему заблагорассудится.
--------------------------------
Подводя итоги. МОЕ ИМХО:
Иметь общий тестовый сервер нельзя и не нужно. Все задачи разработки и тестирования решаются в отдельных средах как описано выше. Поэтому я принципиально не буду обсуждать, как настроить общий сервер и что будет с этого плохого и хорошего. ИМХО - ЭТО НЕДОПУСТИМО, поэтому это направление дискуссии я поддерживать НЕ БУДУ.

Для меня это все равно что обсуждать, какие костыли лучше - алюминиевые или деревянные или с электроникой, позволяющей шевелить пальцами ног. Какие у них достоинства и недостатки. Да один недостаток - костыли это. Я выбираю отказ от костылей, а не дискуссию :-)
14 янв 06, 19:09    [2255199]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
TO GreenSunrise:
На каждой машине собственный MS SQL - это хорошо, пока за каждую лицензию, пусть даже и Developer, не надо деньги платить. За ответ, жесткий, но сраведливый, спасибо. В нем есть ответы почти на все мои вопросы, кроме одного: как и кому синхронизировать между собой локальные базы разработчиков, и не только структуру, но и данные?
К остальным: есть еще варианты?
14 янв 06, 20:10    [2255227]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
_AnotherOne_
Guest
Уважаемый вопрошающий!
Проблема не в том, с какими правами работают разрабы, а в том, что из себя представляют эти разрабы. Для грамотного разраба не стоит проблема в том, под кем работать, грамотный код он напишет под какими угодно правами, даже в блокноте. Если это нужно для общего дела и вы ему доверяете, дайте ему любые права, он борозду не испортит. Если разраб новичок и подает надежду, посадите его за отдельный сервак, дайте ему десктопный сиквел если жалко денег на девелопер, ему этого хватит, заресторьте ему базу на этот сервак, пусть работает, результаты скриптами переносите на продакшн. Если у разраба, как вы говорите, "руки чуть прямее, чем у юзера", лучше избавьтесь от него сразу, это угроза для проекта при любых правах.
2 GreenSunrise
Костыли все, что мешает эффективной работе. Не факт, что на разных серверах в локальных базах порядка будет больше, если разрабы будут сидеть на клавах и курить нервно на рабочем месте. Костыли, ИМХО - это не локальные базы/инстансы/сервера разрабов или общий тестовый сервер, костыли - это кривые руки и кривые мозги, и от этого все беды.
Так что, господа, повышайте квалификацию, дисциплину, ответственность свою и своих коллег. Ограничение прав, файрволы и прочее, не спасут вас и ваш проект сами по себе от кривых рук и мозгов.
Желаю всем успехов и процветания в новом наступившем и последующих годах!
15 янв 06, 13:05    [2255827]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
GuestGuestGuest
как и кому синхронизировать между собой локальные базы разработчиков, и не только структуру, но и данные?

По-разному можно делать. Для определения разницы структур и данных есть утилиты третьих фирм. Да и самим можно написать, это не проблема.

Кто и когда будет вносить эту разницу в ваши конечные скрипты - вопрос чисто административный, ответ на него только вы сами можете дать. У нас это решается просто - check in редактируемых файлов со скриптами в SourceSafe.

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

2 _AnotherOne_: вы ничего не поняли из моего поста. Еще раз повторю: дело не в тупизне кодеров или тестеров или администратора. Дело в том, что ОБЪЕКТИВНО есть задачи, которые НЕВОЗМОЖНО решить в ситуации, когда на тестовом сервере пасутся десятки людей. Квалификация тут вообще ни при чем.
16 янв 06, 11:41    [2257445]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
GuestGuestGuest
TO GreenSunrise:
На каждой машине собственный MS SQL - это хорошо, пока за каждую лицензию, пусть даже и Developer, не надо деньги платить. За ответ, жесткий, но сраведливый, спасибо. В нем есть ответы почти на все мои вопросы, кроме одного: как и кому синхронизировать между собой локальные базы разработчиков, и не только структуру, но и данные?
К остальным: есть еще варианты?

Вы все-таки не читаете посты. Или невнимательно. Как правило, вполне достаточно MSDE. Лицензий не нужно.
Если недостаточно, но нужно иметь лицензию - для этого придуман DeveloperEdition. Раз речь идет о системе, требующей возможностей больших, чем есть в MSDE, нефига пытаться делать "халявку". Можно пустить всех разрабов на один сервак, только бэкапы почаще делать. :) Ибо они подерутся после очередной "пробы пера", убившей все.

Чтобы посмотреть "проблемные места" на "живом" серваке - Админ вводит пароль и пускает программера ПОСМОТРЕТЬ.
Мне пока что всегда хватало скриншотов и логов. Да и админ серева по-хорошему должен уметь разбираться, что такое дедлоки. Если он настоящий админ, конечно. И уметь соответственно давать кодерам отчет не ввиде "У нас тут нифига не работает, козлы!", а "Вы бы разорбрались, почему в момент добавления товара в заказ блокируется таблица CashOperations в случае, когда с другого клиента этот заказ смотрят." Других админов к серваку не подпускать, пароль sa не говорить. ;)

Производительность неплохо повышал с рабочего места.
(Правда, у нас пишется локально статистика времени выполнения процедур и запросов - для отслеживания узких мест. Когда становится скушно, заказываю себе этот файл с любого клиентского места и смотрю, у каких процедур наибольшее время выполнения.)
Даже больше скажу - на быстром серваке сложнее имитировать нагруженную систему, поскольку там обычно конфигурация посильнее, чем ПК у разработчиков. Да и заточено все именно под конкретную базу. Поэтому зачастую время выполнения процедур << 0.001 сек. Вместе с затратами на вызов, транзакцию, сеть и т.д. Тут никакая статистика не поможет.
16 янв 06, 13:26    [2258056]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
автор
Откатов у sysadmina быть не должно:
юзеров выгнал,
базу забэкапил,
скрипты накатил,
если глюк в скриптах - наорал на программеров, восстановил бэкап,
запустил юзеров.


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

Кстати, при разработке на локальных серверах (MSDE) могут возникнуть проблемы синхронизации разных проектов. Возможно, такие проблемы могут быть решены на уже тестировочных серверах...

Nobody faults but mine... (LZ)
16 янв 06, 13:29    [2258075]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
aag
автор
Откатов у sysadmina быть не должно:
юзеров выгнал,
базу забэкапил,
скрипты накатил,
если глюк в скриптах - наорал на программеров, восстановил бэкап,
запустил юзеров.


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

При чем здесь это? Или "Ошибки все равно будут - так давайте сразу на продакшене курочить базу"? ;)
Кстати, если скрипты не затрагивают перестроение таблиц с кучей индексов и сотнями тысяч записей, основное время уйдет только на бэкап. Будь этих скриптов хоть сотня.
А потом - что значит "писать откаты"? Скрипты, которые ОТМЕНЯЮТ изменения, внесенные ДРУГИМ скриптом? Вы когда-нибудь ТАКОЕ делали?
Или это нужно делать руками по-вашему? А если скрипт меняет структуру десятка таблиц, переписывает пару десятков процедур и триггеров - руками откатывать? А если объем скрипта - несколько сотен килобайт (соответственно и количество вносимых "поправок")?

aag
Кстати, при разработке на локальных серверах (MSDE) могут возникнуть проблемы синхронизации разных проектов. Возможно, такие проблемы могут быть решены на уже тестировочных серверах...

Так этого (тестирования) никто не отменял. Изменения сделал - тут же дал команду всем, кто есть под рукой, "синхронизировать исходники/скрипты и оттестировать". С указанием тех мест проекта, которые были затронуты.
А проблемы "синхронизации" решаются просто. Для этого есть менеджер проекта, который определяет, кто из программеров что делает в данный момент и следит, чтобы изменения не перехлестнулись. Менеджером в данном случае может быть просто ведущий программист проекта. Делов-то.
Кстати, автор топика говорит не о тестировочной машине, а именно о допуске программеров к продакшн-серверу.
16 янв 06, 13:56    [2258217]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
2 DeColo®es
Возможно, мы друг друга не поняли. Восстановление базы - весьма дорогая операция. И если в базе живет несколько различных проектов (а так, имхо, чаще всего и есть), то восстановление, как метод отката очередной версии одного из них - неприемлимо. Потому что ошибки в одном проекте вовсе не обязательно затрагивают другой.
Скрипты затрагивают перестроение таблиц с кучей индексов и сотнями тысяч записей? Сделайте копию исходной таблицы. Новые индексы на старый функционал не повлияют, а старые обратно создать можно.
Скрипт "...переписывает пару десятков процедур и триггеров..."? Ну а старые-то остались? Вот вам и откат. Возвращаясь к вашему вопросу "Скрипты, которые ОТМЕНЯЮТ изменения, внесенные ДРУГИМ скриптом? Вы когда-нибудь ТАКОЕ делали?" - делал и неоднократно. Но в подавляющем большинстве случаев откат - это список исходных пр-р, которые должны быть восстановлены.

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

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

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

Автор вообще-то писал - как я его понял - именно о сервере для разработки/тестирования.

Nobody faults but mine... (LZ)
16 янв 06, 16:13    [2259001]     Ответить | Цитировать Сообщить модератору
 Re: Разработчики БД в группе sysadmin?  [new]
GuestGuestGuest
Guest
Имелся ввиду тестовый сервер, на продакшн у нас и данных то никаких нет, кроме эталонных справочников и словарей.
Работаем так:
1.проектируем (MS Visio)
2.генерирум прототип
3.пишем код SP и UDF, отвечающий за бизнес логику. скриптом обновляем тестовый/разрабовский сервер.
4.запускаем тесты на нем, и, если все ОК, то обновляем продакшн, а с него уже - БД заказчиков.
Раньше на тестовом и на своих локальных установках (MS SQL 2000) все разработчики были в группе sysadmin, и еще была встроенная учетная запись sa с общим на все установки паролем, который все разработчики знали. Бардак? Но для этого были причины. Потом поставили на тестовом еще и MS SQL 2005, и на него стали постепенно переводить все проекты. Но на установку MS SQL 2005 сделали только windows-авторизацию, а всех разработчиков поместили в public. Начались проблемы, типа мы раньше делали так, а сейчас этого делать не можем. Понятно, что дело здесь не только в раздаче прав, но все же, как быть? Кто прав? Кто права отобрал или требует их назад?
16 янв 06, 17:37    [2259394]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить