Подготовленный оператор по сравнению с хранимой процедурой

Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.

String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
    System.out.println(phrase.equals(keyPhrase));
}

Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.

Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.

Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.

String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
    System.out.println(phrase.equals(keyPhrase));
}

19
задан Farray 4 September 2011 в 00:02
поделиться

7 ответов

Они не действительно то же самое - с хранимыми процедурами, Ваша логика базы данных находится в базе данных. Подготовленные операторы в основном стараются не повторно анализировать запросы, если их называют многократно - выигрыш в производительности может варьироваться значительно.

выбор использовать один или другой действительно зависит от Вашей определенной ситуации. Я действительно больше не использую сохраненный procs, поскольку мне нравится иметь всю мою логику в одном месте.

28
ответ дан 30 November 2019 в 02:01
поделиться

Некоторые преимущества хранимых процедур:

  • Портативный между языками
  • Возможно упрощенный интерфейс и иногда увеличение производительности для сложных запросов и особенно мультизапрашивают транзакции (тест!)
  • Путем представления интерфейса, а не таблиц, может использоваться для улучшения безопасности и целостности

Некоторые недостатки хранимых процедур:

  • Помещает бизнес-логику в базу данных - усложняет дизайн, дополнительное место для отслеживания для управления версиями и поиска и устранения неисправностей
  • потери Производительности в некоторых ситуациях (тест!)
  • Менее портативный между базами данных

я не думаю, что единственный обобщенный ответ существует для этого вопроса, потому что существуют за и против в зависимости от ситуации. Если Вы будете следовать за принципами как простота, DRY, тестирование и предотвращение преждевременной оптимизации, то Вы, вероятно, закончите прекрасные.

10
ответ дан 30 November 2019 в 02:01
поделиться

Может не иметь место или стоить для упоминания здесь, но хранимые процедуры также являются "портативными" в случае, что они - агностик языка. Можно назвать те же хранимые процедуры на базе данных из, скажем, Java, как Вы были бы с PHP. Поскольку процедуры находятся в базе данных, что-либо с доступом к базе данных может запросить их тот же путь.

4
ответ дан 30 November 2019 в 02:01
поделиться

Существенное преимущество хранимых процедур состоит в том, что Ваши данные не пересекают слой (в этом случае, это был бы уровень PHP/MySQL), прежде чем логика сможет быть применена к нему. Некоторые запросы могут потребовать нескольких избранных операторов, который медленнее сделан через PHP, чем в MySQL.

Теперь, как tobyhede указывает, хорошо иметь всю логику в одном месте. Но я работал над проектами, где было просто нереалистично запросить необходимые данные с помощью PHP; это должно было быть сделано через хранимую процедуру.

2
ответ дан 30 November 2019 в 02:01
поделиться

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

я только рассмотрю хранимую процедуру, если приложение будет 95%-й базой данных, управляемой, только затем делает имеет смысл иметь часть логики в дб.

2
ответ дан 30 November 2019 в 02:01
поделиться

Не знакомый с php, но в общих хранимых процедурах уже "компилируются", так может произвести незначительно более быструю производительность по sql оператору.

, Хотя мое предпочтение обычно, чтобы продолжить работать с SQL от управления кодом / развертывание и перспективу поблочного тестирования.

0
ответ дан 30 November 2019 в 02:01
поделиться

Хранимые процедуры имеют смысл для приложений профессионального уровня (IE уровня предприятия), в которых вы:

  1. хотите, чтобы ваш инженер баз данных оптимизировал запросы для повышения производительности
  2. хотите абстрагироваться от сложности запросы к простым API
  3. ХОЧУ, чтобы ваша логика распространялась, потому что часть того, что происходит в базе данных, может быть интеллектуальной собственностью, которую вы не хотите раскрывать другим сторонам
  4. ХОЧУ, чтобы ваша логика распространялась, потому что это характер распределенной n-уровневые вычисления
  5. Вы можете захотеть, чтобы инженер базы данных или администратор БД изменили схему без изменения кода приложения (хранимые процессы, благодаря предоставлению API, обеспечивают уровень абстракции)

Существуют и другие причины.

Подготовленные заявления лучше подходят для работы, выполняемой в течение сеанса. Но если вы не торопитесь, чтобы создать готовое заявление, вы по сути сделали все необходимое для создания хранимой процедуры. Разница в том, что хранимая процедура доступна в нескольких сеансах (при условии GRANTS в базе данных).

Чего я не могу понять, так это того, что если у вас есть выбор для сохраненной процедуры вместо готового оператора, зачем вам беспокоиться о готовых операторах? Кажется, что большинство дискуссий SP против PS фокусируются на различиях между ними, а не на том, почему использовать одно против другого. Это всегда сводится к тому, что «зависит от того, что вы пытаетесь сделать». Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS, используйте оператор, если вам нужно ...

Разница в том, что хранимая процедура доступна в нескольких сеансах (при условии GRANTS в базе данных).

Чего я не могу понять, так это того, что если у вас есть выбор для сохраненной процедуры вместо готового оператора, зачем вам беспокоиться о готовых операторах? Кажется, что большинство дискуссий SP против PS фокусируются на различиях между ними, а не на том, почему использовать одно против другого. Это всегда сводится к тому, что «зависит от того, что вы пытаетесь сделать». Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS, используйте оператор, если вам нужно ...

Разница в том, что хранимая процедура доступна в нескольких сеансах (при условии GRANTS в базе данных).

Чего я не могу понять, так это того, что если у вас есть выбор для сохраненной процедуры вместо готового оператора, зачем вам беспокоиться о готовых операторах? Кажется, что большинство дискуссий SP против PS фокусируются на различиях между ними, а не на том, почему использовать одно против другого. Это всегда сводится к тому, что «зависит от того, что вы пытаетесь сделать». Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS, используйте оператор, если вам нужно ...

не о том, почему использовать один против другого. Это всегда сводится к тому, что «зависит от того, что вы пытаетесь сделать». Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS, используйте оператор, если вам нужно ...

не о том, почему использовать один против другого. Это всегда сводится к тому, что «зависит от того, что вы пытаетесь сделать». Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS, используйте оператор, если вам нужно ...

25
ответ дан 30 November 2019 в 02:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: