powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Изменение таблиц через ХР, плюсы и минусы
25 сообщений из 119, страница 1 из 5
Изменение таблиц через ХР, плюсы и минусы
    #34004588
LelikBolek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прошу знающих привести плюсы и минусы подхода к работе с таблицами БД (сейчас это FireBird, но светит переход на MSSQL2005) через хранимые процедуры. Довольно часто встречал сообщения что разработчики все изменения таблиц делают через хранимые процедуры. В чем плюсы и минусы такого похода
Сам пока вижу следующие:
- возможность стандартизации процессов редктирования, такие как доп. проверки, протоколирование
А что еще? Ради чего стоит на каждую таблицу делать несколько процедур редактирования? чем-товедь этот подход оправдывается?
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34004602
sqllex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Плюсы.
ХП 1 раз компилятся, для их выполнения строится и сохраняется план, который используется при вызове ХП.
В ХП можно использовать конструкции, которые не поддерживает обычный SQL.

Минус.
Привязка к СУБД.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34004643
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LelikBolekДовольно часто встречал сообщения что разработчики все изменения таблиц делают через хранимые процедуры.
Эффект лемминга. Один сделал так, потому что в его ситуации это дает выигрыш, другой сделал так потому, что видел как делал первый, третий потому что читал, что это может дать выигрыш, четвертый потому что это красиво выглядит, а самое главное - в программу лепится еще один слой и можно с умным видом рассуждать об архитектурных достоинствах...

LelikBolekА что еще?
Ничего. Ни в одном обсуждении мне пока не попалось аргумента, который был бы одновременно достаточно универсальным и мало-мальски объективным (серьезнее уровня "я так привык и мне так нравится и вообще я об этом читал").

Все серьезные аргументы, которые я знаю, выглядят примерно так: в СУБД такой-то из-за такой-то особенности архитектуры вот здесь может быть выигрыш, а в СУБД такой-то такие-то фичи не реализованы и ХП является единственным вариантом решения вот этой задачи.

Вот например вышеназванный "один раз компилятся". Очень популярная легенда, но мне до сих пор никто не назвал СУБД, для которой эта фраза подразумевает реальный выигрыш. Знакомый местным обитателям pkarklin в свое время объяснял мне это на материале MSSQL; в итоге той беседы некто Merle , также известная личность, показал, что даже для MSSQL все обстоит "не совсем так" и если мне не изменяет память (надо бы лезть в поиск) высказал мнение, что в MSSQL ХП в целом не эффективнее запросов.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34004655
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чтобы избежать ненужного флейма, уточню формулировку.

Фраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал. Хотя я готов поверить, что для одной-двух БД такой эффект и может существовать.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34004893
gybson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MS SQL и для запросов планы кэширует
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34004987
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LelikBolekПрошу знающих привести плюсы и минусы подхода к работе с таблицами БД через хранимые процедуры.
Ключевое слово - процедуры, т.е. отдельные подпрограммы. А хранимые они или нет - это вопрос их физического размещения и исполнения (может не совпадать). Выделять в поцедуры и функции полезно все, не только работу с таблицами
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34005003
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Выполнение скомпилированного кода эффективнее изначально, по самой его природе, и не только для sql. Интерпретация предполагает все с самого начала: синтаксический анализ и т.д. и т.п....
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34005266
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
модВыделять в поцедуры и функции полезно все
Слишком глобальное утверждение, чтобы быть всегда и безоговорочно верным.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34005341
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2softwarer
А как насчет, например, удаления и (или) изменение данных только за текущий месяц? И данных за месяц накапливается много и надо удалить например всЁ за этот месяц, как быть?
Или, чтобы юзер не имел прямого доступа к таблицам?
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34005702
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basА как насчет, например, удаления и (или) изменение данных только за текущий месяц? И данных за месяц накапливается много и надо удалить например всЁ за этот месяц, как быть?
Признаться, не понял вопроса. Если нужна операция "удаление всех данных за текущий месяц", скорее всего ее стоит оформить процедурой.

basИли, чтобы юзер не имел прямого доступа к таблицам?
Легко делается без единой ХП. Стоит отметить, что сама постановка вопроса "юзер не имел прямого доступа к таблицам" - кривое решение, пытающееся закрыть проблемы дизайна. Это решение лишь на шаг лучше столь же популярного "юзер вообще не имеет права логиниться на сервер".
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34006146
LelikBolek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
в общем видима подход типа даешь каждой таблице по 2 ХП (встака, удаление) не есь гуд.. значит как работали с FireBird через FibDataSet и SQLInsert, SQLUpdate и т.д. по аналогии нуно и с ADO (для MSSQL2005) тот же путь оптимальнее ... (понятно что это не всегда и не на 100%, я говорю об общем подходе
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34006342
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Одна из наиболее весомых причин применения сабжа - безопасность.
Но я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!!
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34006518
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVОдна из наиболее весомых причин применения сабжа - безопасность.
Хм.

LSVНо я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!!
В моем случае на примерно 1500 таблиц приходилось около 300'000 строк серверного кода. Сколько это "в процедурах" не могу сказать. Пакетов было.. опять же затруднюсь сказать, что-то между несколькими десятками и до пары сотен по субъективным ощущениям.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34006610
gybson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Когда таблиц очень много, есть смысл думать о среднем слое, метаданных и т.п.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34006736
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gybsonКогда таблиц очень много, есть смысл думать о среднем слое, ...
И прелестях работы с 2*N объектами как альтернативе работы с N объектами...

gybsonметаданных
"Думать"? Они уже есть - select в руки.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34006958
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LelikBolekРади чего стоит на каждую таблицу делать несколько процедур редактирования? чем-товедь этот подход оправдывается?Это более технологично - используется однообразный подход к редактированию данных. В качестве бонуса получаем АPI нашего приложения в виде набора хранимых процедур.
softwarerЭффект лемминга. Правильно ли я понимаю Вашу позицию - в системе существует некое количество (часто весьма большое) тривиальных справочников, для которых хранить и вызывать процедуры вставки/удаления/редактирования нецелесообразно?

sqllexМинус.
Привязка к СУБД.Редактирование без использования хранимых процедур, IMHO, привязывает к СУБД еще сильнее :-)
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34007267
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PL99Это более технологично - используется однообразный подход к редактированию данных.
То есть другой столь же однообразный подход менее технологичен? Впрочем, тут более интересен вечный конфликт-компромисс между технологичностью единообразия и нетехнологичностью выбора не лучшего инструмента для конкретного случая.

PL99Правильно ли я понимаю Вашу позицию - в системе существует некое количество (часто весьма большое) тривиальных справочников, для которых хранить и вызывать процедуры вставки/удаления/редактирования нецелесообразно?
Хм. Если говорить о моей позиции в целом, то детально формулировать ее будет несколько громоздко, поэтому тезисно:

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

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

3. Я уверен, что неудачное проектирование взаимодействия сервера с клиентом крайне негативно сказывается на качестве системы, на ее основных параметрах: функциональности, эффективности, сопровождаемости.

PL99Редактирование без использования хранимых процедур, IMHO, привязывает к СУБД еще сильнее :-)
Согласен. Если хочется сделать кросссерверное решение, "целиком процедурное API" является довольно привлекательным подходом (разумеется, не для всех задач, но для тех, которые в целом допускают такое решение).
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34019626
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVНо я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!!
Как говорится, спецально посмотрел, 361 таблица, 5162 процедуры ;)

Правда стоит заметить что процедуры не только ins/del но и вся бизнес логика проведения-отмены документов и все селекты на клиента.

softwarer LSVОдна из наиболее весомых причин применения сабжа - безопасность.
Хм.

Именно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность.

softwarerФраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал.

Лично проводил данный эксперимент еще на 9-ке (по моему она была в 1997 году) Sybase. Необходимо было выбрать часть документов из большой таблицы с привязанными еще десятком таблиц с фильтрацией по 10 полям. Причем часть условий мога быть задана а часть, нет. Вообщем стандартная задача документооборота.

Рассматривались варианты:

1)Создать вьюшку с запросом и динамически создавать WHERE выражение при каждой фильтрации в зависимости от введенных пользователем данных.

SELECT ...
Код: plaintext
1.
2.
3.
FROM v_test
WHERE in_date >= '20050101'
AND doc_sum <  10000 
AND comment LIKE '%qwert%'

2) создать процедуру с 10 аргументами, селектом и условием типа

Код: plaintext
1.
2.
3.
4.
5.
IF @in_date is null
  SELECT @in_date = '17700101'

WHERE in_date >= @in_date
AND (doc_sum < @doc_sum OR @doc_sum is null)
AND comment LIKE '%' + @comment + '%'

Соответственно результатом данного эксперимента было
1-ый вариант 10 секунд (если мне пямять не изменяет)
2-вариант 11 секунд - первый запуск, менее 1 секунды каждый последующий

Правда прошло уже почти 10 лет, последнее время я больше использовал MS SQL. Но не думаю что что-то сильно изменилось.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34019911
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Estets softwarer LSVОдна из наиболее весомых причин применения сабжа - безопасность.
Хм.

Именно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность.softwarer, вероятно, имел ввиду Fine-Grained Access Control в Oracle
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34020037
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EstetsИменно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность.
Именно с хм.

softwarerФраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал.

EstetsЛично проводил данный эксперимент еще на 9-ке (по моему она была в 1997

Соответственно результатом данного эксперимента было
1-ый вариант 10 секунд (если мне пямять не изменяет)
2-вариант 11 секунд - первый запуск, менее 1 секунды каждый последующий

Правда прошло уже почти 10 лет, последнее время я больше использовал MS SQL. Но не думаю что что-то сильно изменилось.
Удручающая картина. Надеюсь, кто-нибудь из местных Sybase-овцев расскажет, действительно ли все так плохо.

Впрочем, в нарисованной Вами постановке не раскрыт один принципиальный вопрос. В первом варианте 10 секунд - это время первого запуска или время любого из последующих?
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34022499
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerУдручающая картина. Надеюсь, кто-нибудь из местных Sybase-овцев расскажет, действительно ли все так плохо.

Впрочем, в нарисованной Вами постановке не раскрыт один принципиальный вопрос. В первом варианте 10 секунд - это время первого запуска или время любого из последующих?
Именно что "любого из последующих" ;(

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

softwarerИменно с хм.
Что касается хм, то тут мне сказать нечего, скажем каждый остался при своем мнении. На счет вставки-изменения-удаления, только через процедуры, спорить даже не буду, так как считаю что невозможно только с помощью триггеров обеспечить большинство бизнес требований по верефикации вводимых-удаляемых данных.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34022598
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EstetsИменно что "любого из последующих" ;(
То есть Вы хотите сказать, что в Sybase принципиально отсутствует кэш планов? Тогда понятно, почему в этом случае процедуры лучше.

Хотя готов подсказать решение "как сделать так, чтобы вышеописанные запросы стали выполняться за 0.1 секунды, в то время как процедура будет продолжать ковыряться по секунде на вызов" :)
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34022712
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EstetsЧто касается хм, то тут мне сказать нечего, скажем каждый остался при своем мнении.
Я тут могу воспользоваться популярным дискуссионным приемом и кивнуть в сторону OEBS. ХП как средство возврата датасетов там практически не используются (не буду говорить "вообще не используются", поскольку для такого проекта очень трудно утверждать с уверенностью), с row-level security проблем не наблюдается.
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34023104
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer EstetsИменно что "любого из последующих" ;(
То есть Вы хотите сказать, что в Sybase принципиально отсутствует кэш планов? Тогда понятно, почему в этом случае процедуры лучше.
Эээээ я этого не говорил ;) Когда выше я описывал пример то прозвучало "Создать вьюшку с запросом и динамически создавать WHERE выражение" а вот в данном случае действительно кэш планов помочь не может, т.к. SELECT ... WHERE doc_date < '20010101' и SELECT ... WHERE doc_date < '20020304' разные селекты.

С OEBS не сталкивался, но работал например с Axapt-ой и сервер приложений прекрасно справляется с row-level security, но все таки сложность написания и поддержки 3-его уровня на мой вглад несколько больше чем, обернуть DML в конструкцию CREATE PROCEDURE AS...
...
Рейтинг: 0 / 0
Изменение таблиц через ХР, плюсы и минусы
    #34023210
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Странно, что скорости тут сравнивают. Интересно, как может повлиять разница кешированного и не кэшированного планов запросов на обновление одной записи с учетом того, что это обновление вызывает клиентское приложение, то есть информацию вводит оператор. Какая может быть скорость ввода у оператора, чтобы стал критичным момент кэширования запросов, да еще с WHERE по PK ??? Моя не понимай

По делу - лично я предпочитаю весь основной показ и изменение информации проводить через представления. Удобно с точки зрения защиты от прямого доступа к таблицам, можно спокойно ограничивать выбор информации нужными условиями, если сервер позволяет в представлении еще использовать UDF, вообще замечательно. Плюс можно ввести дополнительную защиту на проверку изменения информации (для ASA к примеру это WITH CHECK OPTION), которая гарантирует, что представление не даст через себя изменить или добавить информацию, не подходящую под условия, заданные в представлении. Зато как плюс - это полноценный SQL к доступу представления вместо убого вызова процедуры с параметрами (легче сгенерировать UPDATE на одно изменившееся поле, чем через процедуру принудительно обновлять все поля).

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

Как итог хочу сказать, что нельзя в СУБД вырабатывать какие то догмы и тупо всегда ими пользоваться. Лучше вырабатывать гибкие стандарты и пользоваться ими с учетом поставленной задачи. Здесь лично я вижу смысл все писать через ХП только при условии, что платформа создания клиентских приложений не позволяет полноценно обеспечить проведение обновлений представлений и имеет множество ограничений.

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
25 сообщений из 119, страница 1 из 5
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Изменение таблиц через ХР, плюсы и минусы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]