|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
[quot tadminПлюсом APP Сервера на XP является простота языка. Для небольшого проекта достаточно dba и кодера интерфесов/сайта.[/quot] - почему-то вспоминается народная поговорка: "простота - хуже воровства" Сделав "просто", потом получишь воз неразрешимых проблем (решить которые можно двумя способами - либо все полностью переделать, либо, как в каком-то из постов: DBA становится президентом компании и выгоняет всех недовольных разработчиков) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 14:20 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
vadiminfobaike2000Итак, СУБД - MS SQL, клиент .NET, раньше Visual Basic. Процедура возвращает набор данных просто. Ну в теле процедуры обычный select col1,col2 from tbl, можно с параметрами в where. Есть еще процедуры update, insert, delete для одной записи. Соответственно, если удаляется 100 записей из грида, то сто раз вызывается процедура удаления. И никаких блокировок. Ну напиши те плиз простейший пример, чтобы была видна специфакция этого набора в частности. Ну и как выглядит вызов на клиенте. Язык Васик? Язык C#. Даже и не знаю что вам показать. Примеров лежит масса в интернете... Ну вот кусок, правда с пессимистической блокировкой, здесь не надо оптимистическую по логике программы. Но если добавить тех же параметров и написать в них Код: plaintext
вот определение команд. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80.
Вот вызов на клиенте dsUpdate - dataSet. Соответственно компонент вызовет update, delete, insert только для именных записей. Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 14:30 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Kachalov - почему-то вспоминается народная поговорка: "простота - хуже воровства" Сделав "просто", потом получишь воз неразрешимых проблем (решить которые можно двумя способами - либо все полностью переделать, либо, как в каком-то из постов: DBA становится президентом компании и выгоняет всех недовольных разработчиков) Эсхатологический прогноз. Мы пока с этим не столкнулись. И вообще выбор технологически простых путей не так опасен потребителя, как убыточен для поставщика решений -) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 15:04 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
baike2000, с писсимстической вопросов то нет: просто for update пишется в SQL, которая в ХП. А пример этих самых dbo.ShowIntlMetaCodes? Простой: внутри SQL и было видно, шо за тип она возвращает. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 15:14 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
baike2000 вот определение команд. Я правильно понимаю, что если бы процедур не было, а просто использовались sql-операторы, то код был бы почти таким же? Если да, то в чем преимущества процедур для данного случая? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 15:14 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Kachalov- блин, ну вот опять, говорите прямо что все что не Oracle, то не СУБД Не надо выдирать слова из контекста, тем более что с Оракл я как раз и не работаю. Я в основном работаю с DB2 :) И писал я об эффективной обработке триггеров/вью/ХП в СУБД, а не о качестве СУБД в целом. Хотя... :) KachalovP.S. Для людей с ограниченным кругозором: хостинг для баз и конкретно на Oracle существует (ради интереса посетите сайт Oracle: тынц )Вот спасибо, кругозор раширился беспредельно! Я и хостинг с DB2 могу указать, речь-то шла о Kachalovпример из жизни: человек приносит сайт использующий ХП на хостинг и оказывается что ему нужен более дорогой тарифный план чем он предполагал, так как хостер не дает ему привилегий необходимых для создания и исполнения ХП в рамках shared-хостинга.Вы всерьез считаете, что БД сколько-ни серьезной системы может жить мало того что на shared-хостинге, но даже и без прав создания ХП? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 15:24 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
baike2000, Я не правильно понял Дельфишников. Оказывается дело не в курсоре. А дело в не спользовании ДатаСета. А c ним разницы нет курсор и SQL в ХП или SQL в клиенте. Но все равно спасибо. Просто там использовались другие компоненты. Я наталкнулся на то, шо не работает в одной проге оптимистическая блокировка и решил, это из-за курсоров. А теперь после Вашего ответа опять стал выяснять у них и все прояснилось. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 16:06 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
без курсора (набора данных в табличном виде) в хранимках трудно обойтись. Например простая процедура Код: plaintext 1. 2. 3. 4. 5.
которая возвращает курсор. ЗЫ. Если БД-импотент, тогда конечно.... можно всё на других слоях писать. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 16:14 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
FavnВы всерьез считаете, что БД сколько-ни серьезной системы может жить мало того что на shared-хостинге, но даже и без прав создания ХП? - я считаю что для "серьезной системы" вообще ХП не нужны. Кстати что Вы называете "серьезной системой"? Систему нагруженную большим количеством несложных запросов (OLTP) или малонагруженную систему с большими сложноструктурированными таблицами по которым периодически необходимо строить отчеты (OLAP)? Если мы говорим о web-приложениях (иначе с какого боку тут вообще хостинг?), то очевидно что подавляющее большинство таких систем относится к типу OLTP-приложений, которые прекрасно могут обходиться без ХП и где использование ХП означает скорее архитектурную безграмотность разработчика, а не реальную необходимость. P.S. про масштабирование и кластеризацию в контексте ХП что-то никто не хочет опонировать :) Вопросы типа: "сколько стоит кластеризуемая БД?" явно оказались неудобными ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 17:07 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Kachalov - я считаю что для "серьезной системы" вообще ХП не нужны. не будьте максималистом. - как вы реализуете без XP мой запрос выше? - как насчёт вьюх, триггеров, ключей, каскадов и других средств удобных для разработчика серверной части ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 17:39 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Kachalov - я считаю что для "серьезной системы" вообще ХП не нужны. юношеский максимализм, с годами проходит. KachalovP.S. про масштабирование и кластеризацию в контексте ХП что-то никто не хочет опонировать :) Вопросы типа: "сколько стоит кластеризуемая БД?" явно оказались неудобными да опонировать собственно нечему. вы с апп-серверами кластерами дел не имели, проблемы возникающие с репликацией кеша того же jboss вам не знакомы. в субд тоже кластера разные бывают, есть shared-nothing c вариантами типа mpp, есть shared-disk кластера, есть in-memory кластера аля mysql. найдите спеца по кластеризации апп-серверов подискутируем. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 17:43 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Petro123не будьте максималистом. Yo.!юношеский максимализм, с годами проходит - для того чтобы вести разумный разговор об использовании ХП, необходимо предварительно определиться с задачей где именно их планируется использовать. Уважаемые пользователи ХП в "серьезных системах", пожалуйста потрудитесь сформулировать что такое "серьезная система", после чего диалог возможно преодолеет детсадовский уровень и обретет подобие смысла. Кстати насчет максимализма - лично я считаю что в OLAP системах использование ХП может иметь смысл (извиняюсь, за то что не хочу с пеной у рта доказывать что ХП это полная фигня, а вот ORM это круто и надо его пихать в любую задницу) Yo.!вы с апп-серверами кластерами дел не имели, проблемы возникающие с репликацией кеша того же jboss вам не знакомы. найдите спеца по кластеризации апп-серверов подискутируем. - Вы демонстрируете поразительное знание меня - польщен! Прошу Вас не отвлекаться от задачи захвата планеты Земля и уничтожения всех противников ХП :) Жду не дождусь когда выяснится что сервером приложений Вы называете СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 18:47 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Petro123- как вы реализуете без XP мой запрос выше? - честно говоря не уловил о каком запросе шла речь Petro123- как насчёт вьюх, триггеров, ключей, каскадов и других средств удобных для разработчика серверной части ? - некоторые вещи не нужны (потому что иначе реализуются или относятся к другим задачам), другие реализованы на программном уровне (уровне сервера приложений). В любом случае, архитектура и средства реализации архитектуры зависят от задачи, в связи с чем говорить ХП/вью/триггер/и т. п. не нужны или нужны бессмысленно. Единственно серьезным из своих постов в данной теме считаю этот пост , все остальное флуд порожденный тупо-агрессивной позицией DBA не желающих изучать что-то кроме возможностей своей БД (другие БД им тоже обычно ненавистны), в связи с чем опасающихся потерять работу из-за приложений где прослойка в виде DBA просто не нужна ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 18:59 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Kachalov ...не желающих изучать что-то кроме возможностей своей БД (другие БД им тоже обычно ненавистны), в связи с чем опасающихся потерять работу... из-за приложений где прослойка в виде DBA просто не нужна Отличное понимание принципов функционирования рынка! Kachalov ...прослойка в виде DBA просто не нужна Тоже посмеялся ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 19:17 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
KachalovtadminПлюсом APP Сервера на XP является простота языка. Для небольшого проекта достаточно dba и кодера интерфесов/сайта. - почему-то вспоминается народная поговорка: "простота - хуже воровства" Сделав "просто", потом получишь воз неразрешимых проблем (решить которые можно двумя способами - либо все полностью переделать, либо, как в каком-то из постов: DBA становится президентом компании и выгоняет всех недовольных разработчиков) Насчет простоты языка полностью согласен с tadmin. Еще подчеркну лаконичность конструкций и ненужность сопряжения контекста приложения и контекста РБД (мы работаем все время в контексте РБД). У меня ХП размером в 30 строк обычно заменяет исходный код строк эдак в 100-150 на клиенте. И для себя я давно вывел аксиому фильтра, где должна находиться бизнес-логика : как только код какого-то процесса-расчета (то есть элемента БЛ) на клиенте превышает 5 строк - выношу его на сервер (как вьюшку, триггер, ХП ...). Понятное дело, что с повторно используемым кодом все усложняется - так на то есть как библиотеки классов на клиенте, так и наборы функций на сервере. Кстати сказать. Есть некоторые исключения из правил (в приятную сторону). В ProgressDB код ХП, код клиентских приложений и код БЛ пишется на одном и том же языке (4GL), и в одном контексте можно объединить все сразу. На этой платформе 3-х звенка стала естественной (и если бы не малая распространенность и связанные с этим некоторые досадные мелочи - завоевала бы мир). Кстати, за то, что здесь на одном языке пишешь все, но в трехуровневой архитектуре, Progress называют "сетевым Foxpro". Насчет "воза неразрешимых проблем" ... Тут частично согласен с Kachalov. Проблемы сопровождаемости через какое-то время нарастают до, казалось бы, неприличного уровня. Но это связано с периодами изменчивости самого бизнеса. А эта самая изменчивость - величина непостоянная. Пережил месяц головняка, получил премию за внедрение нового БП - и пол-года минимум почиваешь на лаврах занимаешься более приятными вещами занимаешься другими проектами и абсолютно нэ пэрэймаешься "сложной системой" - она живет себе и живет. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 22:47 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
KachalovУважаемые пользователи ХП в "серьезных системах", пожалуйста потрудитесь сформулировать что такое "серьезная система" "Серьезная система" - это программная система, работающая в режиме 24*7 и обеспечивающая потребности бизнеса, генерирующего годовую добавочную стоимость в размере в 1000 раз больше затрат на создание этой программной системы. В ее составе OLTP-база данных, нагруженная большим количеством сложных и простых запросов, и OLAP-база (необязательно). Kachalovнеобходимо предварительно определиться с задачей где именно их (ХР) планируется использовать Дык, это ... определились уже и используем 10 лет как в этих самых "серьезных системах". Kachalovлично я считаю что в OLAP системах использование ХП может иметь смысл Гм. А зачем ХП в OLAP-базе ? Кубы дополнять - на то MSIS есть. Интеллектуальный анализ делать ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 23:04 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
strizh"Серьезная система" - это программная система, работающая в режиме 24*7 и обеспечивающая потребности бизнеса, генерирующего годовую добавочную стоимость в размере в 1000 раз больше затрат на создание этой программной системы. В ее составе OLTP-база данных, нагруженная большим количеством сложных и простых запросов, и OLAP-база (необязательно). - под Ваше определение вполне подходит какой-нибудь успешный web-проект :) Ведь Вы наверняка не это имели в виду а так все четко: 24x7 - не дай бог сайт 5 минут не работает, у хостера начинаются звонки от клиента с угрозами доб. стоимость в 1000 раз (с какого потолка взяли?) больше стоимости создания - видел проекты по продаже билетов в Интернет с такими показателями, в принципе видел некоторые успешные SEO-проекты которые тоже дают похожую прибыль - тут фишка в том чтобы система не очень дорого стоила, а для веба это характерно. база данных, нагруженная большим количеством сложных и простых запросов (что-то не так с нормализацией Вашей базы или с архитектурой, тут либо много простых и мало сложных, либо только сложные и все заросло травой с 90-х) - в общем Вы определитесь с OLAP или OLTP, т. е. в специфике системы, но и то и другое есть в web-проектах Вот и выходит что "сложная система" - это, в том числе, не особо крупный и нагруженный сайт Еще люблю когда говорят "большой проект" - Фрейда на вас нет, вообще ХЗ что, то ли бюджет большой, то ли база толстая, то ли нагрузка высокая. strizh Дык, это ... определились уже и используем 10 лет как в этих самых "серьезных системах". - про "серьезные системы" написал выше. Кстати Вы когда-нибудь видели ТЗ в котором использовался термин "серьезная система"? Скорее всего нет - отсюда вывод "серьезные системы" делают без ТЗ и без документации. Извините за стеб (он адресован не Вам лично), но просто не могу удержаться. strizh Гм. А зачем ХП в OLAP-базе ? Кубы дополнять - на то MSIS есть. Интеллектуальный анализ делать ? - а зачем они в OLTP? выходит что не нужны они нигде? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2010, 23:35 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Bogdanov Andrey, Так у меня процедуры на Update и delete не простые все таки. Я ее чуть под редактирую, но все равно вам будет понятно, что на клиенте мне это делать не улыбается. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 07:27 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
strizh И для себя я давно вывел аксиому фильтра, где должна находиться бизнес-логика : как только код какого-то процесса-расчета (то есть элемента БЛ) на клиенте превышает 5 строк - выношу его на сервер (как вьюшку, триггер, ХП ...). +1 Kachalov не путайте архитектуру и ТЗ на web-проект и НЕ web-проект. В том числе сабж (ХП) в web проектах имеет мЕньшее значение. Так уж исторически сложилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 09:52 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
baike2000что на клиенте мне это делать не улыбается."Не улыбается" это что значит? На языке клиента это сделать нельзя? Или это будет существенно сложнее? Ни в то ни в другое я не верю. Или лично вам T-SQL более приятен на вид? О вкусах не спорю, но речь не о вкусах шла, а о преимуществах. Естественно, что в случаях, когда речь идет об операции включающей некую "бизнес-логику", то появляется вопрос о месте реализации этой логики (в ХП или в другом слое) и в данном случае я ничуть не возражаю против ХП. Но апологеты процедур здесь декларировали какие-то преимущества процедур для абсолютно всех случаев, в том числе и не обремененных бизнес-логикой. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 10:57 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Bogdanov Andreybaike2000что на клиенте мне это делать не улыбается. .... в том числе и не обремененных бизнес-логикой. например? Никто такого не говорил. Я прихожу к такому выводу, что "кто что знает, .... тот там и пишет" :) IMHO - БЛ неотрывна от данных - данные без БЛ никому не нужны - если данные - РЕЛЯЦИОННЫЕ по своей природе, то где их обрабатывать по бизнесу, если не в БД (рядом с БД :) ) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 11:14 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Bogdanov Andreybaike2000что на клиенте мне это делать не улыбается."Не улыбается" это что значит? На языке клиента это сделать нельзя? Или это будет существенно сложнее?В данном случае на стороне клиента это будет как минимум медленнее работать, т.к. придётся делать внешнее управление транзакциями. Bogdanov AndreyЕстественно, что в случаях, когда речь идет об операции включающей некую "бизнес-логику", то появляется вопрос о месте реализации этой логики (в ХП или в другом слое) и в данном случае я ничуть не возражаю против ХП.Да, главным образом рассматривается этот случай. В примере baike2000 бизнес логика в хп есть. Bogdanov AndreyНо апологеты процедур здесь декларировали какие-то преимущества процедур для абсолютно всех случаев, в том числе и не обремененных бизнес-логикой.Да, есть и некоторые преимущества процедур для абсолютно всех случаев, которые тут уже описывали. Например, вынесение работы с данными в один слой и разработка этого слоя соотв. специалистами при наличии хп будет удобнее. Другое дело, что нужно оценивать величину этих преимуществ - конечно, процедуры совсем не обязательно использовать всегда. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 11:38 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Petro123например? Никто такого не говорил. На этом форуме не раз уже обсуждался подход с использованием CRUD (или SUID) процедур. Можете воспользоваться поиском. Также предлагаю посмотреть на название топика - оно предполагает, что обсуждаются преимущества (или недостатки) появляющиеся при замене обычных SQL-запросов процедурами. С недостатками мне все ясно, а вот про преимущества я хотел бы услышать, но пока никто ничего вразумительного не сказал. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 11:45 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
Bogdanov AndreyPetro123например? Никто такого не говорил. На этом форуме не раз уже обсуждался подход с использованием CRUD (или SUID) процедур. Можете воспользоваться поиском. ===== это не имеет отношения к сабжу. Или так скажем, граничный случай (инсерт только через процу). CRUD - разделение на 2 слоя ВНУТРИ БД Также предлагаю посмотреть на название топика - оно предполагает, что обсуждаются преимущества (или недостатки) появляющиеся при замене обычных SQL-запросов процедурами. С недостатками мне все ясно, ==== мне нет (Я не предлагаю CRUD). а вот про преимущества я хотел бы услышать, но пока никто ничего вразумительного не сказал. ==== тебе виднее, всё уже написано "БЛ - на сервер" - этим всё сказано. Удачи! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 11:56 |
|
Хранимые процедуры против обычных SQL-запросов
|
|||
---|---|---|---|
#18+
alexeyvgДа, главным образом рассматривается этот случай. Бессмысленно рассматривать этот случай. SQL - язык для работы с реляционными данными, а не язык для реализации бизнес логики. Глупо говорить о том, что прецедуры имеют преимущества перед SQL, так как позволяют реализовать бизнес-логику. С таким же успехом можно утверждать, что танк лучше мерседеса, так как стрелять умеет. В таких бессымысленных сравнениях я участвовать не буду. alexeyvgДа, есть и некоторые преимущества процедур для абсолютно всех случаев, которые тут уже описывали. Например, вынесение работы с данными в один слой и разработка этого слоя соотв. специалистами при наличии хп будет удобнее.А нельзя ли поподробнее это преимущество расписать. Что значит "удобнее" и почему? Мне, например, кажется, что удобнее просто создать таблицу, а потом в соответствующем классе на Java написать четыре SQL-оператора, чем городить еще и промежуточный слой в виде четырех хранимых процедур внутрь которых эти операторы запрятаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2010, 11:57 |
|
|
start [/forum/topic.php?fid=33&msg=36407090&tid=1548373]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 160ms |
0 / 0 |