Показать сообщение отдельно
Старый 16.06.2009, 15:17   #6  
Bishop is offline
Bishop
Участник
 
89 / 60 (3) ++++
Регистрация: 12.08.2004
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
Это до тех пор пока вы проектами все обновляете. А когда объем доработок большой, а время простоя базы не более часа в неделю -
то приходится слоем обновлять - для таких случаев актуально чтобы id-ники выделялись в одном месте и не менялись.
Цитата:
Сообщение от raz Посмотреть сообщение
Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.
Очень смелое утверждение!

У меня абсолютно противоположное мнение. В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки. А если все же дело доходит до проектов (в крайних случаях), то экспорт/импорт только с идентификаторами.
И вот почему:
1) Не все клиенты покупают лицензии на разработку, и опция "инкрементная компиляция" у них отсутствует.
2) Не у всех клиентов есть лицензии на разработку в тех слоях, в которых ведет разработку партнер. Если у вас разработка в VAR, а в рабочем приложении
все "лежит" на CUS или USR - это, как минимум, выглядит криво.
3) Как обновить проектом удаленную (переименованную) в разработке форму/таблицу/класс/...?
4) Если рабочее приложение развернуто на нескольких АОСах (да еще и с балансировщиком), обновление проектом может привести как раз к ОЧЕНЬ большому геморрою (особенно при наличии новых таблиц/полей, как показала практика).
5) При различиях в идентификаторах таблиц и полей невозможно (в общем случае) корректно подменить данные приложения разработки из рабочей базы при помощи резервного копирования и восстановления (а такая необходимость иногда возникает).
6) В "стандарте" нет инструментов, позволяющих проверять, что проект включает все "затронутые" объекты, и это "проверяется" лишь на этапе импорта.

В добавок к этому, обновление проектами ухудшает качество разработки, т.к. всегда можно "быстренько все подправить", если что...
За это сообщение автора поблагодарили: Dron AKA andy (2).