PHP Oracle Query Data на основе массива в таблице

Question

PHP Oracle Query Data на основе массива в таблице

1

У меня есть выражение оракула sql.

табличные данные:

FORM_NO | PART_NO | CHUTTER_ID
1       | ABC     | 1,3,9,12,15

У меня есть переменная PHP

$get_q = "3";

Теперь я хочу запросить:

$q = oci_parse($c1, "SELECT * FROM tb_test WHERE CHUTTER_ID IN '$get_q'");
oci_execute($q);

Результат запроса пуст.

Кто-нибудь знает, как это решить?

HiDayurie Dave 09 фев. 2016, в 09:08

Источник

Теги:

php

oracle

1 ответ

Ещё вопросы

trincot · Accepted Answer · 2016-02-09T05-43-00.000Z

Вы можете написать тест следующим образом:

"SELECT * FROM tb_test WHERE ',' || CHUTTER_ID || ',' LIKE '%,$get_q,%'"

Это добавляет запятую значение CUTTER_ID, чтобы оно стало чем-то вроде:

,1,3,9,12,15,

Затем он проверяет, что приведенное выше соответствует этому шаблону:

%,3,%

где a % представляет 0 для любого количества символов. Дополнительные запятые необходимы, чтобы убедиться, что 1 и 15 будут найдены с помощью этого метода.

О вашем исходном запросе

Ваш запрос недействителен, потому что оператор IN требует, чтобы правильный аргумент был списком в скобках, например (3), без кавычек. Но даже если вы это сделаете, вы получите это выражение:

CUTTER_ID IN (3)

это как сказать:

'1,3,9,12,15' IN (3)

Но это не имеет смысла. Вы хотите протестировать обратное:

3 in (1,3,9,12,15)

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

SQL-инъекция

Обратите внимание, что если значение "3" в вашем примере происходит от ввода пользователя, ваш код уязвим для SQL-инъекции. Чтобы этого избежать, привяжите значение через oci_bind_by_name, например:

$q = oci_parse($c1, "SELECT * FROM tb_test 
                     WHERE ',' || CHUTTER_ID || ',' LIKE '%,' || :p1 || ',%'");
oci_bind_by_name($stid, ':p1', $get_q);
oci_execute($q);

Дизайн базы данных

Наконец, список значений в одном поле базы данных не является признаком хорошей модели базы данных. Это пример базы данных, которая не нормализована. Он даже не соответствует первой форме нормализации.

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