|
|
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Прошу знающих привести плюсы и минусы подхода к работе с таблицами БД (сейчас это FireBird, но светит переход на MSSQL2005) через хранимые процедуры. Довольно часто встречал сообщения что разработчики все изменения таблиц делают через хранимые процедуры. В чем плюсы и минусы такого похода Сам пока вижу следующие: - возможность стандартизации процессов редктирования, такие как доп. проверки, протоколирование А что еще? Ради чего стоит на каждую таблицу делать несколько процедур редактирования? чем-товедь этот подход оправдывается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2006, 21:30 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Плюсы. ХП 1 раз компилятся, для их выполнения строится и сохраняется план, который используется при вызове ХП. В ХП можно использовать конструкции, которые не поддерживает обычный SQL. Минус. Привязка к СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2006, 21:50 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
LelikBolekДовольно часто встречал сообщения что разработчики все изменения таблиц делают через хранимые процедуры. Эффект лемминга. Один сделал так, потому что в его ситуации это дает выигрыш, другой сделал так потому, что видел как делал первый, третий потому что читал, что это может дать выигрыш, четвертый потому что это красиво выглядит, а самое главное - в программу лепится еще один слой и можно с умным видом рассуждать об архитектурных достоинствах... LelikBolekА что еще? Ничего. Ни в одном обсуждении мне пока не попалось аргумента, который был бы одновременно достаточно универсальным и мало-мальски объективным (серьезнее уровня "я так привык и мне так нравится и вообще я об этом читал"). Все серьезные аргументы, которые я знаю, выглядят примерно так: в СУБД такой-то из-за такой-то особенности архитектуры вот здесь может быть выигрыш, а в СУБД такой-то такие-то фичи не реализованы и ХП является единственным вариантом решения вот этой задачи. Вот например вышеназванный "один раз компилятся". Очень популярная легенда, но мне до сих пор никто не назвал СУБД, для которой эта фраза подразумевает реальный выигрыш. Знакомый местным обитателям pkarklin в свое время объяснял мне это на материале MSSQL; в итоге той беседы некто Merle , также известная личность, показал, что даже для MSSQL все обстоит "не совсем так" и если мне не изменяет память (надо бы лезть в поиск) высказал мнение, что в MSSQL ХП в целом не эффективнее запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2006, 22:45 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Чтобы избежать ненужного флейма, уточню формулировку. Фраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал. Хотя я готов поверить, что для одной-двух БД такой эффект и может существовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2006, 23:05 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
MS SQL и для запросов планы кэширует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 08:50 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
LelikBolekПрошу знающих привести плюсы и минусы подхода к работе с таблицами БД через хранимые процедуры. Ключевое слово - процедуры, т.е. отдельные подпрограммы. А хранимые они или нет - это вопрос их физического размещения и исполнения (может не совпадать). Выделять в поцедуры и функции полезно все, не только работу с таблицами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 09:33 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Выполнение скомпилированного кода эффективнее изначально, по самой его природе, и не только для sql. Интерпретация предполагает все с самого начала: синтаксический анализ и т.д. и т.п.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 09:38 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
модВыделять в поцедуры и функции полезно все Слишком глобальное утверждение, чтобы быть всегда и безоговорочно верным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 10:49 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
2softwarer А как насчет, например, удаления и (или) изменение данных только за текущий месяц? И данных за месяц накапливается много и надо удалить например всЁ за этот месяц, как быть? Или, чтобы юзер не имел прямого доступа к таблицам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 11:01 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
basА как насчет, например, удаления и (или) изменение данных только за текущий месяц? И данных за месяц накапливается много и надо удалить например всЁ за этот месяц, как быть? Признаться, не понял вопроса. Если нужна операция "удаление всех данных за текущий месяц", скорее всего ее стоит оформить процедурой. basИли, чтобы юзер не имел прямого доступа к таблицам? Легко делается без единой ХП. Стоит отметить, что сама постановка вопроса "юзер не имел прямого доступа к таблицам" - кривое решение, пытающееся закрыть проблемы дизайна. Это решение лишь на шаг лучше столь же популярного "юзер вообще не имеет права логиниться на сервер". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 12:15 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
в общем видима подход типа даешь каждой таблице по 2 ХП (встака, удаление) не есь гуд.. значит как работали с FireBird через FibDataSet и SQLInsert, SQLUpdate и т.д. по аналогии нуно и с ADO (для MSSQL2005) тот же путь оптимальнее ... (понятно что это не всегда и не на 100%, я говорю об общем подходе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 13:46 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Одна из наиболее весомых причин применения сабжа - безопасность. Но я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 14:28 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
LSVОдна из наиболее весомых причин применения сабжа - безопасность. Хм. LSVНо я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!! В моем случае на примерно 1500 таблиц приходилось около 300'000 строк серверного кода. Сколько это "в процедурах" не могу сказать. Пакетов было.. опять же затруднюсь сказать, что-то между несколькими десятками и до пары сотен по субъективным ощущениям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 15:11 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Когда таблиц очень много, есть смысл думать о среднем слое, метаданных и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 15:33 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
gybsonКогда таблиц очень много, есть смысл думать о среднем слое, ... И прелестях работы с 2*N объектами как альтернативе работы с N объектами... gybsonметаданных "Думать"? Они уже есть - select в руки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 16:10 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
LelikBolekРади чего стоит на каждую таблицу делать несколько процедур редактирования? чем-товедь этот подход оправдывается?Это более технологично - используется однообразный подход к редактированию данных. В качестве бонуса получаем АPI нашего приложения в виде набора хранимых процедур. softwarerЭффект лемминга. Правильно ли я понимаю Вашу позицию - в системе существует некое количество (часто весьма большое) тривиальных справочников, для которых хранить и вызывать процедуры вставки/удаления/редактирования нецелесообразно? sqllexМинус. Привязка к СУБД.Редактирование без использования хранимых процедур, IMHO, привязывает к СУБД еще сильнее :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 17:11 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
PL99Это более технологично - используется однообразный подход к редактированию данных. То есть другой столь же однообразный подход менее технологичен? Впрочем, тут более интересен вечный конфликт-компромисс между технологичностью единообразия и нетехнологичностью выбора не лучшего инструмента для конкретного случая. PL99Правильно ли я понимаю Вашу позицию - в системе существует некое количество (часто весьма большое) тривиальных справочников, для которых хранить и вызывать процедуры вставки/удаления/редактирования нецелесообразно? Хм. Если говорить о моей позиции в целом, то детально формулировать ее будет несколько громоздко, поэтому тезисно: 1. Я полагаю правильным "не плодить сущности без необходимости", а также уверен, что качество системы обратно пропорционально количеству тупого (dumb) кода в ней. 2. Я полагаю, что выбор оптимального решения - не такая простая тема; не слишком формализуемая и определенно не подходящая для рассуждений на пальцах. 3. Я уверен, что неудачное проектирование взаимодействия сервера с клиентом крайне негативно сказывается на качестве системы, на ее основных параметрах: функциональности, эффективности, сопровождаемости. PL99Редактирование без использования хранимых процедур, IMHO, привязывает к СУБД еще сильнее :-) Согласен. Если хочется сделать кросссерверное решение, "целиком процедурное API" является довольно привлекательным подходом (разумеется, не для всех задач, но для тех, которые в целом допускают такое решение). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 18:59 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
LSVНо я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!! Как говорится, спецально посмотрел, 361 таблица, 5162 процедуры ;) Правда стоит заметить что процедуры не только ins/del но и вся бизнес логика проведения-отмены документов и все селекты на клиента. softwarer LSVОдна из наиболее весомых причин применения сабжа - безопасность. Хм. Именно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность. softwarerФраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал. Лично проводил данный эксперимент еще на 9-ке (по моему она была в 1997 году) Sybase. Необходимо было выбрать часть документов из большой таблицы с привязанными еще десятком таблиц с фильтрацией по 10 полям. Причем часть условий мога быть задана а часть, нет. Вообщем стандартная задача документооборота. Рассматривались варианты: 1)Создать вьюшку с запросом и динамически создавать WHERE выражение при каждой фильтрации в зависимости от введенных пользователем данных. SELECT ... Код: plaintext 1. 2. 3. 2) создать процедуру с 10 аргументами, селектом и условием типа Код: plaintext 1. 2. 3. 4. 5. Соответственно результатом данного эксперимента было 1-ый вариант 10 секунд (если мне пямять не изменяет) 2-вариант 11 секунд - первый запуск, менее 1 секунды каждый последующий Правда прошло уже почти 10 лет, последнее время я больше использовал MS SQL. Но не думаю что что-то сильно изменилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:20 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Estets softwarer LSVОдна из наиболее весомых причин применения сабжа - безопасность. Хм. Именно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность.softwarer, вероятно, имел ввиду Fine-Grained Access Control в Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:25 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
EstetsИменно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность. Именно с хм. softwarerФраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал. EstetsЛично проводил данный эксперимент еще на 9-ке (по моему она была в 1997 Соответственно результатом данного эксперимента было 1-ый вариант 10 секунд (если мне пямять не изменяет) 2-вариант 11 секунд - первый запуск, менее 1 секунды каждый последующий Правда прошло уже почти 10 лет, последнее время я больше использовал MS SQL. Но не думаю что что-то сильно изменилось. Удручающая картина. Надеюсь, кто-нибудь из местных Sybase-овцев расскажет, действительно ли все так плохо. Впрочем, в нарисованной Вами постановке не раскрыт один принципиальный вопрос. В первом варианте 10 секунд - это время первого запуска или время любого из последующих? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:51 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
softwarerУдручающая картина. Надеюсь, кто-нибудь из местных Sybase-овцев расскажет, действительно ли все так плохо. Впрочем, в нарисованной Вами постановке не раскрыт один принципиальный вопрос. В первом варианте 10 секунд - это время первого запуска или время любого из последующих? Именно что "любого из последующих" ;( Может сейчас Sybase и ускорил построение планов, и соответственно разница будет не столь заметная, но что было то было. softwarerИменно с хм. Что касается хм, то тут мне сказать нечего, скажем каждый остался при своем мнении. На счет вставки-изменения-удаления, только через процедуры, спорить даже не буду, так как считаю что невозможно только с помощью триггеров обеспечить большинство бизнес требований по верефикации вводимых-удаляемых данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 15:02 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
EstetsИменно что "любого из последующих" ;( То есть Вы хотите сказать, что в Sybase принципиально отсутствует кэш планов? Тогда понятно, почему в этом случае процедуры лучше. Хотя готов подсказать решение "как сделать так, чтобы вышеописанные запросы стали выполняться за 0.1 секунды, в то время как процедура будет продолжать ковыряться по секунде на вызов" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 15:23 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
EstetsЧто касается хм, то тут мне сказать нечего, скажем каждый остался при своем мнении. Я тут могу воспользоваться популярным дискуссионным приемом и кивнуть в сторону OEBS. ХП как средство возврата датасетов там практически не используются (не буду говорить "вообще не используются", поскольку для такого проекта очень трудно утверждать с уверенностью), с row-level security проблем не наблюдается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 15:48 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
softwarer EstetsИменно что "любого из последующих" ;( То есть Вы хотите сказать, что в Sybase принципиально отсутствует кэш планов? Тогда понятно, почему в этом случае процедуры лучше. Эээээ я этого не говорил ;) Когда выше я описывал пример то прозвучало "Создать вьюшку с запросом и динамически создавать WHERE выражение" а вот в данном случае действительно кэш планов помочь не может, т.к. SELECT ... WHERE doc_date < '20010101' и SELECT ... WHERE doc_date < '20020304' разные селекты. С OEBS не сталкивался, но работал например с Axapt-ой и сервер приложений прекрасно справляется с row-level security, но все таки сложность написания и поддержки 3-его уровня на мой вглад несколько больше чем, обернуть DML в конструкцию CREATE PROCEDURE AS... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 17:12 |
|
||
|
Изменение таблиц через ХР, плюсы и минусы
|
|||
|---|---|---|---|
|
#18+
Странно, что скорости тут сравнивают. Интересно, как может повлиять разница кешированного и не кэшированного планов запросов на обновление одной записи с учетом того, что это обновление вызывает клиентское приложение, то есть информацию вводит оператор. Какая может быть скорость ввода у оператора, чтобы стал критичным момент кэширования запросов, да еще с WHERE по PK ??? Моя не понимай По делу - лично я предпочитаю весь основной показ и изменение информации проводить через представления. Удобно с точки зрения защиты от прямого доступа к таблицам, можно спокойно ограничивать выбор информации нужными условиями, если сервер позволяет в представлении еще использовать UDF, вообще замечательно. Плюс можно ввести дополнительную защиту на проверку изменения информации (для ASA к примеру это WITH CHECK OPTION), которая гарантирует, что представление не даст через себя изменить или добавить информацию, не подходящую под условия, заданные в представлении. Зато как плюс - это полноценный SQL к доступу представления вместо убого вызова процедуры с параметрами (легче сгенерировать UPDATE на одно изменившееся поле, чем через процедуру принудительно обновлять все поля). Если же логика получения информации или сохранения изменений требует от клиентского приложения множества сложных действий, то я пишу хранимые процедуры. Бывают ситуации, когда к примеру приложение получает данные через хранимку, а изменение информации проводит по представлению или наоборот. Так же к примеру получение и изменение информации я провожу исключительно только через хранимые процедуры для вебовских приложений с учетом того, что вводятся множество других параметров и условий, которые было бы не выгодно выносить на логику веб приложения, усложняя его. Как итог хочу сказать, что нельзя в СУБД вырабатывать какие то догмы и тупо всегда ими пользоваться. Лучше вырабатывать гибкие стандарты и пользоваться ими с учетом поставленной задачи. Здесь лично я вижу смысл все писать через ХП только при условии, что платформа создания клиентских приложений не позволяет полноценно обеспечить проведение обновлений представлений и имеет множество ограничений. -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 17:39 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34004893&tid=1544980]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
137ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 481ms |

| 0 / 0 |
