Который лучше: Специальные запросы или хранимые процедуры? [закрытый]
ниже код может быть помещен в основной метод
// TODO Auto-generated method stub
Integer[] a = { 11, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 3, 4, 1, 2, 2, 2, 2, 3, 4, 2 };
List<Integer> list = new ArrayList<Integer>(Arrays.asList(a));
Set<Integer> set = new HashSet<Integer>(list);
int highestSeq = 0;
int seq = 0;
for (int i : set) {
int tempCount = 0;
for (int l : list) {
if (i == l) {
tempCount = tempCount + 1;
}
if (tempCount > highestSeq) {
highestSeq = tempCount;
seq = i;
}
}
}
System.out.println("highest sequence is " + seq + " repeated for " + highestSeq);
22 ответа
По моему опыту, при записи главным образом приложений для Клиента/сервера WinForms это простые заключения, в которые я приехал:
Хранимые процедуры Использования:
- Для любой сложной работы данных. Если Вы собираетесь быть выполнением чего-то действительно требование курсора или временных таблиц, это является обычно самым быстрым, чтобы сделать это в SQL Server.
- , Когда необходимо заблокировать вниз доступ к данным. Если Вы не предоставляете доступ таблицы к пользователям (или роль, или безотносительно) можно быть уверены, что единственный способ взаимодействовать с данными через SP, который Вы создаете.
специальные запросы Использования:
- Для CRUD, когда Вы не должны ограничивать доступ к данным (или делают так другим способом).
- Для простых поисков. Создание SP для набора критериев поиска является болью и трудный поддержать. Если можно генерировать довольно быстрое использование поискового запроса это.
В большинстве моих приложений я использовал и и специальный sql SP, хотя я нахожу, что использую SP все меньше и меньше, поскольку они заканчивают тем, что были кодом точно так же, как C#, только тяжелее к управлению версиями, тесту, и поддерживают. Я рекомендовал бы использовать специальный sql, если Вы не можете найти определенную причину не к.
он хорошая архитектура системы, если Вы позволяете подключению 1 000 рабочих столов непосредственно к базе данных?
No это, очевидно, не, это - возможно, плохой пример, но я думаю мнение, которое я пытался высказать, ясно, Ваш DBA заботится о Вашей инфраструктуре базы данных, которая это, были их экспертные знания, наполнение SQL в коде блокирует дверь им и их экспертным знаниям.
В эти дни я почти никогда не использую хранимые процедуры. Я только использую их для сложных запросов SQL, которые не могут легко быть сделаны в коде.
Одна из главных причин - то, потому что хранимые процедуры не работают также с ИЛИ картопостроители.
В эти дни я думаю, что Вам нужно очень серьезное основание записать бизнес-приложение / информационная система, которая не использует своего рода ИЛИ картопостроитель.
Я предпочитаю сохранять все данные доступ логика в коде программы, в котором уровень доступа к данным выполняет прямые SQL-запросы. С другой стороны, данные управление логика я вставил базу данных в форме триггеров, хранимых процедур, пользовательских функций и этажерки. Примером чего-то, что я считаю достойными базы-данных-ifying, является поколение данных - предполагают, что у нашего клиента есть FirstName и LastName. Теперь, пользовательскому интерфейсу нужен DisplayName, который получен из некоторой нетривиальной логики. Для этого поколения я создаю хранимую процедуру, которая тогда выполняется триггером каждый раз, когда строка (или другие исходные данные) обновляется.
, кажется, существует это несколько распространенное заблуждение, что уровень доступа к данным ЯВЛЯЕТСЯ базой данных, и все о доступе к данным и доступе к данным идет туда "просто потому что". Это просто неправильно, но я вижу много проектов, которые происходят из этой идеи. Возможно, это - локальное явление, все же.
я могу просто быть выключен идея SPS после наблюдения такого количества плохо разработанных. Например, один проект, я участвовал в используемом ряде хранимых процедур CRUD для каждой таблицы и каждого возможного запроса, с которым они встретились. При этом они просто добавили другой абсолютно бессмысленный слой. Это болезненно для ровного размышления о таких вещах.
Мой опыт состоит в том, что 90% запросов и/или хранимых процедур не должны быть записаны вообще (по крайней мере, вручную).
Доступ к данным должен быть сгенерирован так или иначе автоматически. Можно решить, требуется ли статично генерировать процедуры во время компиляции или динамично во время выполнения, но когда Вы хотите, добавляет столбец к таблице (свойство к объекту), необходимо изменить только один файл.
Зависит, какова Ваша цель. Если Вы хотите получить список объектов, и это происходит однажды во время всего выполнения Вашего приложения, например, это, вероятно, не стоит усилия по использованию хранимой процедуры. С другой стороны, запрос, который неоднократно работает и занимает (относительно) долгое время для выполнения, является превосходным кандидатом на устройство хранения данных базы данных, так как производительность будет лучше.
, Если Ваше приложение живет почти полностью в базе данных, хранимые процедуры являются легкой задачей. Если Вы пишете настольное приложение, которому база данных является только мимоходом важными, специальными запросами, может быть более оптимальный вариант, поскольку это сохраняет весь Ваш код в одном месте .
@Terrapin: Я думаю Ваше утверждение, что то, что Вы не должны перекомпилировать свое приложение для создания модификаций, делает хранимые процедуры, более оптимальным вариантом является обреченное на неудачу. Могут быть причины предпочесть хранимые процедуры специальным запросам, но в отсутствие чего-либо еще принуждение, проблема компиляции походит на лень, а не настоящую причину.
Я не нашел убедительного аргумента в пользу использования специальных запросов. Особенно перепутанные с Вашим кодом C#/Java/PHP.
SQL Parametized или SPROC... не имеют значения от точки зрения производительности..., можно запросить, оптимизируют любой.
Для меня последнее остающееся преимущество SPROC - то, что я могу устранить много управления правами SQL, только предоставив моим правам входа в систему выполнить sprocs..., если Вы используете SQL Parametized скручивание жгутов входа в систему, Ваша строка подключения имеет намного больше прав (пишущий ЛЮБОЙ вид избранного оператора на одной из таблиц, у них есть доступ, слишком например).
я все еще предпочитаю SQL Parametized хотя...
Procs по причинам, упомянутым другими и также, легче настроить proc с профилировщиком или частями proc. Таким образом, Вы не должны говорить кому-то запускать его приложение для обнаружения то, что отправляется на SQL-сервер
, Если Вы действительно используете специальные запросы, удостоверяются, что они параметризованы
Хранимые процедуры являются большими, потому что они могут быть изменены без того, чтобы перекомпилировать. Я попытался бы использовать их максимально часто.
я только использую для данного случая для запросов, которые динамично сгенерированы на основе ввода данных пользователем.
Некоторые вещи думать о здесь: , Кому нужны Хранимые процедуры, Так или иначе?
Очевидно это - вопрос Ваших собственных потребностей и предпочтений, но одна очень важная вещь думать о том, когда использование специальных запросов в стоящей с общественностью среде является безопасностью. Всегда параметризуйте их и не упустите типичные уязвимости как АТАКИ С ИСПОЛЬЗОВАНИЕМ КОДА НА SQL .
кто-то сказал, что это перекомпилировало, ленивое оправдание! да позволяет, видят, как ленивый Вы чувствуете, когда необходимо перекомпилировать и развернуть приложение на 1000-х рабочих столов, все, потому что DBA сказал Вам, что Ваш специальный запрос съедает слишком много времени Сервера!
он хорошая архитектура системы, если Вы позволяете подключению 1 000 рабочих столов непосредственно к базе данных?
Процедуры хранилища должны использоваться как можно больше, если Ваш SQL записи в код Ваша уже установка себя для головных болей во фьючерсах. Это берет в то же время для записи SPROC, как это делает для записи его в коде.
Рассматривают запрос, который работает большой при средней загрузке, но как только это входит в полностью занятое производство, Ваш плохо оптимизированный запрос кует систему и приносит ее к проверке. В большинстве SQL-серверов Вы не единственное приложение/сервис, которое использует его. Ваше приложение теперь принесло набор сердитых людей у Вашей двери.
, Если у Вас есть свои запросы в SPROCs, Вы также позволяете Вашему дружественному DBA управлять и оптимизировать с перекомпиляцией или повреждением Вашего приложения. Помните, что DBA является экспертами в этом поле, они знают, что сделать и не сделать. Имеет смысл использовать их большее знание!
РЕДАКТИРОВАНИЕ: кто-то сказал, что это перекомпилировало, ленивое оправдание! да позволяет, видят, как ленивый Вы чувствуете, когда необходимо перекомпилировать и развернуть приложение на 1000-х рабочих столов, все, потому что DBA сказал Вам, что Ваш специальный запрос съедает слишком много времени Сервера!
Существуют убедительные аргументы и в пользу - хранимые процедуры все расположены в центральном репозитории, но (потенциально) тверды мигрировать и специальные запросы, легче отладить, как они с Вашим кодом, но их может также быть более трудно найти в коде.
аргумент, что хранимые процедуры более эффективны, больше не выдерживает критики. текст ссылки
Выполнение Google для Хранимой процедуры по сравнению с Динамическим Запросом покажет достойные аргументы так или иначе и вероятно лучше всего для Вас для принятия собственного решения...
В нашем приложении существует слой кода, который обеспечивает содержание запроса (и иногда вызов к хранимой процедуре). Это позволяет нам:
- легко имеют все запросы при управлении версиями
- для создания то, что когда-либо изменяется, требуются, чтобы, каждый запрос для различных серверов баз данных
- устраняет повторение того же кода запроса через наш код
, Управление доступом реализовано в среднем слое, а не в базе данных, таким образом, нам не нужны хранимые процедуры там. Это - до некоторой степени средняя дорога между специальными запросами и сохраненным procs.
Мой ответ от различного сообщение: Хранимые процедуры [еще 112] удобный в сопровождении потому что:
- Вы не должны перекомпилировать свое приложение C# каждый раз, когда Вы хотите изменить некоторый SQL
- , Вы заканчиваете тем, что снова использовали код SQL.
повторение Кода хуже вещь, которую можно сделать, когда Вы пытаетесь создать удобное в сопровождении приложение!
, Что происходит, когда Вы находите логическую ошибку, которая должна быть исправлена в нескольких местах? Вы более склонны забыть изменять то последнее пятно, где Вы копируете & вставляемый Ваш код.
, По-моему, производительность & усиления безопасности являются добавленным плюс. можно все еще записать небезопасные/неэффективные хранимые процедуры SQL.
Легче к порту к другому DB - никакой procs к порту
Это не очень твердо к сценарию все Ваши хранимые процедуры для создания в другом DB. На самом деле - это легче , чем экспорт Ваших таблиц, потому что нет никаких основных / внешних ключей для волнения о.
Хранимые процедуры являются определенно способом пойти..., они компилируются, имеют план выполнения перед рукой, и Вы могли сделать управление правами на них.
я не понимаю эту целую проблему управления исходным кодом о хранимой процедуре. Вы определенно можете управление исходным кодом их, если только Вы немного дисциплинируетесь.
Всегда запускаются с .sql файла, который является источником Вашей хранимой процедуры. Поместите его в управление версиями, как только Вы записали свой код. В следующий раз Вы хотите отредактировать свою хранимую процедуру, получают его от Вашего управления исходным кодом, чем Ваша база данных. Если Вы будете следовать за этим, Вы будете иметь как хорошее управление исходным кодом как Ваш код.
я хотел бы заключить Tom Kyte в кавычки из Oracle здесь... Вот его правило о том, где записать код..., хотя немного не связанный, но хороший для знания я предполагаю.
- Запускаются с хранимых процедур в МН / SQL...
- , Если Вы думаете, что в чем-то нельзя выполнить с помощью МН хранимой процедуры / SQL, используйте хранимую процедуру Java.
- , Если Вы думаете, что что-то не может быть сделано с помощью Хранимой процедуры Java, рассмотреть Pro*c.
- , Если Вы думаете, что не можете достигнуть чего-то с помощью Pro*C, Вы могли бы хотеть заново продумать то, что Вы должны быть сделаны.
Я думаю, что это - основной конфликт между людьми, которые должны поддержать базу данных и людей, которые разрабатывают пользовательские интерфейсы.
Как человек данных, я не рассмотрел бы работу с базой данных, к которой получают доступ через специальные запросы, потому что их трудно эффективно настроиться или справиться. То, как я могу знать то, что влияет на изменение в схеме, будет иметь? Кроме того, я не думаю, что пользователи должны когда-либо быть предоставленным прямым доступом к таблицам базы данных из соображений безопасности (и я только имею в виду атаки с использованием кода на SQL, но также и потому что это - основной внутренний контроль, чтобы не позволить прямые права и потребовать, чтобы все пользователи использовали только procs, разработанный для приложения. Это должно предотвратить возможное мошенничество. Любая финансовая система, которая позволяет прямую вставку, обновление или удаляет права на таблицы, имеет огромный риск для мошенничества. Это - плохая вещь.).
Базы данных не объектно-ориентированы и кодируют, который кажется хорошим с объектно-ориентированной точки зрения, может быть чрезвычайно плохим с точки зрения базы данных.
Наши разработчики говорят нам, что они рады, что весь наш databse доступ через procs becasue, это делает его намного быстрее, чтобы исправить центрируемую данными ошибку и затем затем выполнить proc на продуктивной среде, а не создать новое ответвление кода и перекомпилировать и перезагрузить к производству. Мы требуем, чтобы весь наш procs был в подрывной деятельности, таким образом, управление исходным кодом не является проблемой вообще. Если это не будет в Подрывной деятельности, это будет периодически отбрасываться dbas, таким образом, не будет никакого сопротивления использованию Управления исходным кодом.
Хранимые процедуры представляют контракт программного обеспечения, который инкапсулирует меры, принятые против базы данных. Код в процедурах, и даже схема самой базы данных может быть изменена, не влияя на скомпилированный, развернутый код, именно так вводы и выводы процедуры остаются тем же.
Путем встраивания запросов в приложение, Вы сильно связываете себя к своей модели данных.
По той же причине, это - также не хорошая практика для простого создания хранимых процедур, которые являются просто запросами CRUD против каждой таблицы в базе данных, так как это - все еще плотное соединение. Процедуры должны вместо этого быть большими, крупномодульными операциями.
С точки зрения безопасности, это - хорошая практика, чтобы запретить db_datareader и db_datawriter из Вашего приложения и только предоставить доступ к хранимым процедурам.
Я ни с чем не могу говорить кроме SQL Server, но аргумент производительности не значительно допустим там, если Вы не находитесь на 6,5 или ранее. SQL Server кэшировал специальные планы выполнения примерно в течение десятилетия теперь.
Хранимая процедура работает как блок кода, поэтому вместо специального запроса она работает быстро. Другое дело, что хранимая процедура дает возможность перекомпиляции, которая является лучшей частью SQL, вы просто используете это для хранимых процедур, ничего подобного в специальном запросе.
Некоторые результаты запроса и хранимой процедуры отличаются, это мой личный опыт. Для проверки используйте функцию приведения и скрытия.
Необходимо использовать хранимые процедуры для больших проектов, чтобы повысить производительность.
У меня было 420 процедур в моем проекте, и они отлично работают. Я работаю над этим проектом последние 3 года.
Так что используйте только процедуры для любой транзакции.
Аргумент производительности sproc спорный - 3 самых популярных RDBM используют кэширование плана запроса, и это уже некоторое время. Это задокументировано ... Или все еще 1995 год?
Однако встраивание SQL в ваше приложение - тоже ужасный замысел - многим кажется, что обслуживание кода отсутствует.
Если приложение может запускаться с нуля с помощью ORM (новых приложений очень мало!), Это отличный выбор, поскольку ваша модель класса управляет вашей моделью БД - и экономит МНОГО времени.
Если инфраструктура ORM недоступна, мы использовали гибридный подход к созданию XML-файла ресурсов SQL для поиска строк SQL по мере необходимости (они затем кэшируются структурой ресурсов). Если SQL требует каких-либо незначительных манипуляций, это делается в коде - если необходимы серьезные манипуляции со строкой SQL, мы переосмысливаем подход.
Этот гибридный подход упрощает управление разработчиками (возможно, мы меньшинство, поскольку моя команда достаточно умна, чтобы читать план запроса), а развертывание - это простая проверка из SVN. Кроме того, это упрощает переключение RDBM - просто замените файл ресурсов SQL (конечно, не так просто, как ORM-инструмент, но при подключении к устаревшим системам или неподдерживаемой базе данных это работает)