Люди. Я скорей с опросом, чем с вопросом.

Расскажите как Вы используете ХП?
Конкретно меня инетересует:
Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?

Заранее спасибо.

Здравствуйте, Аноним, Вы писали:


А>Люди. Я скорей с опросом, чем с вопросом.
А>Расскажите как Вы используете ХП?
А>Конкретно меня инетересует:
А>Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?

Непонятно:
Во-первых — какая СУБД?
Во-вторых — что "все"?
В-третьих — если опрос, то может лучше в голосования?

Мы вообще всю (ну почти всю) логику делаем в хранимых процедурах.
Клиент или веб-сервер отвечают только за интерфейс.
СУБД — Oracle

Почти все в ХП.

СУБД — MS SQL Server

Здравствуйте, Пацак, Вы писали:

П>Здравствуйте, Аноним, Вы писали:


А>>Люди. Я скорей с опросом, чем с вопросом.
А>>Расскажите как Вы используете ХП?
А>>Конкретно меня инетересует:
А>>Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?

П>Непонятно:
П>Во-первых — какая СУБД?
П>Во-вторых — что "все"?
П>В-третьих — если опрос, то может лучше в голосования?

1.СУБД впринципе не важна, важен сам смысл. А вообще MS SQL.
2.Ну например мне нужно сделать селект 2 полей из таблички. Писать для этого ХП или Query использовать?
3.Надо подумать

Инструмент выбирается по задачу.

Здравствуйте, Аноним, Вы писали:

А>Расскажите как Вы используете ХП?

с использованием ХП — с ними гораздо проще, да и правильней рулить правами

а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Расскажите как Вы используете ХП?

А>с использованием ХП — с ними гораздо проще, да и правильней рулить правами

Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
Причем в 2 из них придется передавать 30 параметров.
Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>Расскажите как Вы используете ХП?

А>>с использованием ХП — с ними гораздо проще, да и правильней рулить правами

А>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>Причем в 2 из них придется передавать 30 параметров.
А>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

Вообще то речь в цитируемом посте шла об управлении безопасностью.

А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

Здравствуйте, Аноним, Вы писали:

А>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>Причем в 2 из них придется передавать 30 параметров.
А>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

Ну, канечно, проще с TADOQuery. Особенно если все запихано в одну таблицу. А вот представьте себе, когда структуру данных нормализована по самое не хочу и то, что пользователь вводит в 30 контролов на форме распихивается в 10 таблиц в бд. Как вы тут одним TADOQuery выкрутитесь? Да и кроме простых операций по изменения данных, обычно в хп закладывают бизнес логику. При этом доступа к таблицам вообще нет. И вся работа организуется через Вызов соответсвующих хп.

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

Здравствуйте, tpg, Вы писали:

tpg>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, Аноним, Вы писали:

А>>>>Расскажите как Вы используете ХП?

А>>>с использованием ХП — с ними гораздо проще, да и правильней рулить правами

А>>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>>Причем в 2 из них придется передавать 30 параметров.
А>>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

tpg>Вообще то речь в цитируемом посте шла об управлении безопасностью.

Упс.... про безопасность проглядел. Сорри
Если говорить про безопасноссть и она очень нужна, то согласен ХП помогут


tpg>А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

Поверьте это бывает достаточно часто, какими бы умными и головастыми аналитики не были
Просто есть клиент, который платит деньги, отсюда и все проблеммы ...

Здравствуйте, Аноним, Вы писали:

tpg>>А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

А>Поверьте это бывает достаточно часто, какими бы умными и головастыми аналитики не были
А>Просто есть клиент, который платит деньги, отсюда и все проблеммы ...

Я ещё вел речь об архитекторах.
Абсолютно согласен с pkarklin насчет нормализации и распределения бизнес-логики (да и при применении N-слойной архитектуры с применением ХП ещё никто не помер )...

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>>Причем в 2 из них придется передавать 30 параметров.
А>>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

P>Ну, канечно, проще с TADOQuery. Особенно если все запихано в одну таблицу. А вот представьте себе, когда структуру данных нормализована по самое не хочу и то, что пользователь вводит в 30 контролов на форме распихивается в 10 таблиц в бд. Как вы тут одним TADOQuery выкрутитесь? Да и кроме простых операций по изменения данных, обычно в хп закладывают бизнес логику. При этом доступа к таблицам вообще нет. И вся работа организуется через Вызов соответсвующих хп.

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

P>Другой аспект. Предположим, что Вы работаете непосредственно с таблицами (представлениями) с клиента, т.е. с явно зашитыми в клиента инструкциями по модификации данных. А теперь представьте себе, что возникла необходимость в изменении структуры хранения или алгоритма обработки. И мы лезем в проект, правим там, компилируем и ... теперь нам надо все это обновить у пользователей. Если используются хп, то их изменение в большинстве случаев не требует изменения клиентского приложения.

С этим соглашусь

Здравствуйте, tpg, Вы писали:

tpg>Здравствуйте, Аноним, Вы писали:

tpg>>>А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

А>>Поверьте это бывает достаточно часто, какими бы умными и головастыми аналитики не были
А>>Просто есть клиент, который платит деньги, отсюда и все проблеммы ...

tpg>Я ещё вел речь об архитекторах.
tpg>Абсолютно согласен с pkarklin насчет нормализации и распределения бизнес-логики (да и при применении N-слойной архитектуры с применением ХП ещё никто не помер )...

Что никто не помер это понятно вопрос в количестве заморочек, которые эта архитектура порождает ...

Здравствуйте, Аноним, Вы писали:

А>Нормализация должна быть разумной Я видел много программ и в них карточка клиента это много полей в одной таблице ... поверьте так проце всего.

Если мы говорим об OLTP системах, то номализация должна быть как раз "по самое не хочу". Только так можно добиться максимального быстродействия в транзакционной системе. Я тоже видел много программ, в которых были таблицы не по одному десятку полей, в которых 80% полей содержали NULL, что никак не добавляло быстродействию системы.

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Нормализация должна быть разумной Я видел много программ и в них карточка клиента это много полей в одной таблице ... поверьте так проце всего.

P>Если мы говорим об OLTP системах, то номализация должна быть как раз "по самое не хочу". Только так можно добиться максимального быстродействия в транзакционной системе. Я тоже видел много программ, в которых были таблицы не по одному десятку полей, в которых 80% полей содержали NULL, что никак не добавляло быстродействию системы.

не люблю NULL

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Нормализация должна быть разумной Я видел много программ и в них карточка клиента это много полей в одной таблице ... поверьте так проце всего.

P>Если мы говорим об OLTP системах, то номализация должна быть как раз "по самое не хочу". Только так можно добиться максимального быстродействия в транзакционной системе. Я тоже видел много программ, в которых были таблицы не по одному десятку полей, в которых 80% полей содержали NULL, что никак не добавляло быстродействию системы.

А еще клево, когда нет FK в базе

А>Люди. Я скорей с опросом, чем с вопросом.
А>Расскажите как Вы используете ХП?
А>Конкретно меня инетересует:
А>Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?


Я не предпочитаю в основном,
т.к. часто стоит потребность работать с разными базами данных.

кроме того раньше они применялсиь для прекомпиляции — на слабых процах,
а теперь это не так актуально,

кроме того в АДО можно даже отдать команду — "прекомпилировать".


Когда же запросы сложные и извращенные по оптимизации,
на страницы кода,
тогда их удобно все-таки вынести в отдельный модуль — ХП.

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

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

Безопастностью же можно рулить кучей и других способов,
как в СOM+ — ведь это образец? — декларативная и интегрируемая безопастности.

Здравствуйте, vgrigor, Вы писали:

А>>Люди. Я скорей с опросом, чем с вопросом.
А>>Расскажите как Вы используете ХП?
А>>Конкретно меня инетересует:
А>>Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?


V>Я не предпочитаю в основном,
V>т.к. часто стоит потребность работать с разными базами данных.

V>кроме того раньше они применялсиь для прекомпиляции — на слабых процах,
V>а теперь это не так актуально,

V>кроме того в АДО можно даже отдать команду — "прекомпилировать".


V>Когда же запросы сложные и извращенные по оптимизации,
V>на страницы кода,
V>тогда их удобно все-таки вынести в отдельный модуль — ХП.

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

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

V>Безопастностью же можно рулить кучей и других способов,
V>как в СOM+ — ведь это образец? — декларативная и интегрируемая безопастности.


Согласен со увсем
Могу добавить что MSSQL(про других не знаю), планы исполнения не только процедур, но и обычных запросов хранит вместе с планами процедур.
И получается что при грамотном написании запросов(используя параметры), можно повысить скорость выполения запросов.

Здравствуйте, Аноним, Вы писали:

А>А еще клево, когда нет FK в базе
Ничего смешного. Многие высокопроизводительные системы именно так и работают.