> не заморачиваясь на dependences.
ну почему же? все учитывается.

В общем, я сторонник метода инкрементных изменений.
Дабы не устраивать холивар, все читаем статью:
http://habrahabr.ru/blogs/sql/121265/

статья дерьмо, автор комнатный теоретик.

Моя ситуация:
программа не коммерческая, а типа сдается в аренду другим юрлицам, которые работают с нами.

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

В общем "работать должно всегда" и "ниипет-пишется раздельно".

Вы им графоманские статьи с хабара в нос, а они вам : "а ниипет, должно работать"

К тому же:

клиент получил версию №1.
поработал немного и затих.
прошло полгода.
вышло 10 новых версий.
клиент просыпается запускает версию №1 и обновляется до версии 11.

итого:
либо мне надо хранить все версии, а ему тупо их выкачивать и обновляться десять раз, либо его 11 версия не сможет взлететь с его версией базы №1.

> клиент получил версию №1.
> ...
> клиент просыпается запускает версию №1 и обновляется до версии 11.
аналогично.

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

> типа база главное, ее типа обслуживает, правит куча народу/программ,
>  а программы типа неважны...

Откуда такой вывод? Там четко написано: "Версия базы данных должна соответствовать версии приложения."

> ну почему же? все учитывается.




Что выдаст MSSQL на drop?

> Откуда такой вывод?
общее впечатление. база всегда на первом месте.

> Что выдаст MSSQL на drop?
не в состоянии сначала удалить процедуру (тригер/констраинт/т.д.), если она есть?
что по твоему значит "учитывается"?

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

> Что выдаст MSSQL на drop?
и тест - говорит
Выполнено применительно к -1 записям. (no recordset)
конкретно тут нет зависимости

> конкретно тут нет зависимости


Я об этом в [10] и говорил.


> не в состоянии сначала удалить процедуру (тригер/констраинт/т.
> д.), если она есть?


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

> И таки мне эта концепция не нравится. Вот как в MSSQL - нравится.
???, именно с mssql я и работаю. в основном. и применяю данную концепцию.

> то замучаешься удалять.
1
> и к тому же, обычно не удаляется, обычно добавляется. выше версия, больше функционала в программе (иначе какой смысл изменениях?), больше используемых данных/"шире" структура в базе.
это глюк в основах логики программы/структуре базы, если приходится удалять.
2
не вижу смысла "делить логику", и выносить часть в процедуры, опять "просвечивает" подход - типа "база главное и мощное, весь пентагон на ее обслуживание работает, а программа это, что-то незначительное сбоку".
если можно, и легко сделать в программе, зачем процедуры? кто-то сказал что без них несерьезно? а реально они нужны?

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

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


Ну вот реальный пример, аккурат с ним тут на днях возился.
Есть таблица документов. Есть иерархическая таблица разделов. есть кросс-таблица "Документ-раздел".
При удалении раздела ссылки на документы, в нём сидящие, не должны быть удалены, а должны апдетиться на корневой раздел.
Без хп или триггера (скорее - триггера) решать задачу замучаешься.


> обычно не удаляется, обычно добавляется


Это хорошо, если так. Но, тем не менее, шанс - есть. Глюк, не до конца продуманная логика, новые требования - это уже другой вопрос.


>  "база главное и мощное, весь пентагон на ее обслуживание
> работает, а программа это, что-то незначительное сбоку".


Я этого не говорил, побойся Б-га.

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

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

> пакет их 2х команд, апдейта и удаления завернутые в транзакцию.


А зачем, если можно одной командой сделать?

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

> но программа уже логическими частями "расползлась" в 2 места.
>  разрыв логики.


Интересная точка зрения.
Надо обдумать.

> > но программа уже логическими частями "расползлась" в 2 места.  
разрыв логики.
>
> Интересная точка зрения.
> Надо обдумать.

Да, если программа одна - две.

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

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

> тогда идеологически база "главная", а программы это так,
>  "приблуды". а в конце мы уже обсуждали другое, вариант
> когда программа "имеет базу", а не "база программу".


Не так. Когда программа + база суть единое целое - тогда можно и ХП.
Когда либо программа "может меняться" или их несколько, либо СУБД может меняться - тогда да, надо думать.