Как передать имя таблицы как параметр?

Question

[gvg1]

Пока хватало типа такого:

$s='SELECT a, b FROM t WHERE a=:a';
$q=$pdo->prepare($s);
$q->bindParam(':a',$a,PDO::PARAM_STR);
$q->execute();
$m=$q->fetchAll(PDO::FETCH_ASSOC);

Но таблиц стало много и неопределённо много.
Захотелось сделать так:

$s='SELECT a, b FROM :t WHERE a=:a';
$q=$pdo->prepare($s);
начало цикла по t
$q->bindParam(':t',$t,PDO::PARAM_STR);
$q->bindParam(':a',$a,PDO::PARAM_STR);
$q->execute();
$m=$q->fetchAll(PDO::FETCH_ASSOC);
конец цикла

Ожидаемо получил
Syntax error or access violation: 1064 You have an error in your SQL syntax

Можно сделать так:

начало цикла по t
$s='SELECT a, b FROM '.$t.' WHERE a=:a';
$q=$pdo->prepare($s);
$q->bindParam(':a',$a,PDO::PARAM_STR);
$q->execute();
$m=$q->fetchAll(PDO::FETCH_ASSOC);
конец цикла

Как выкрутиться, чтобы prepare выполнять только один раз?

Comments

[mr Anderson]

Дружище, изначальная цель недостижима в текущем виде, так как SQL и PDO не позволяют параметризовать идентификаторы
Поскольку SQL-запросы не поддерживают параметризацию идентификаторов (например, имени таблицы или столбцов)

Имеет ограничение, в связи с:
- создаёт угрозу SQL-инъекций
- параметры заменяются только для значений, а идентификаторы (таблицы, столбцы, базы данных) должны быть известны на этапе компиляции SQL-запроса

[Vitsliputsli]

Я бы не назвал это ограничением, параметризация имени таблицы бессмыслена. Т.к. таблицы известны, это не бессмысленный набор символов. И, главное, оптимизатор не сможет построить план для неизвестной таблицы.

Answer 1

[Алексей Уколов]

Никак.

Answer 2

[Akina]

Но таблиц стало много и неопределённо много.

Вижу два варианта.

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

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

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

На строго в рамках PDO - полностью согласен с предыдущим оратором. Никак.

Comments

[Vitsliputsli]

На строго в рамках PDO - полностью согласен с предыдущим оратором. Никак.

Не совсем понимаю, что это значит. Какая разница какой интерфейс доступа к бд. Что нам мешает использовать динамический sql в pdo?
Если речь не про pdo, а про prepared statements, то опять же, что нам мешает и здесь использовать динамический sql. Если вопрос инъекций, то также как вы описали для процедур - используем белый список. А байндить как переменную не резон, т.к. это не переменная.

[Akina]

Vitsliputsli, я о том, что у PDO есть конструкция для подстановки параметра-литерала, но нет таковой для подстановки имени объекта. В некоторых фреймворках есть (если я верно помню, в каком-то с одной @ это параметр, а с двумя объект - но не спрашивайте, что за фреймворк, не помню, а искать лень), с такими же по сути проверками.

Если вопрос инъекций, то также как вы описали для процедур - используем белый список.

В общем случае ненадёжно. Ибо в большинстве collation есть несовпадающие, но считающиеся равными, символы, а в некоторых так и вовсе игнорируемые. Именно поэтому подставляем не переданное значение, а литерал:

CASE tablename
...
    WHEN 'table1' THEN SET @sql := CONCAT(@sql, ' FROM table1');
...

Конечно, при конкатенации переданного значения опасности инъекции нет, но вот положить финальный запрос в syntax error или unknown name - как два пальца.

[Vitsliputsli]

Akina,

у PDO есть конструкция для подстановки параметра-литерала, но нет таковой для подстановки имени объекта

Это не PDO, это prepared statements. А с точки зрения последних подстановка имени таблицы бессмыслица. Здесь в комментариях описал почему.
Ну а в коде можно сделать что угодно.
PDO конечно имеет свою реализацию, но это эмуляция, т.е. попытка повторить для замены.

В общем случае ненадёжно

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

Answer 3

[Ипатьев]

В 99% случаев, необходимость подставлять таблицу в запрос динамически говорит о говнокоде.
А в данном случае даже гадать не нужно - этот цикл и "неопределённо много таблиц" - это уже стопроцентнтный говнокод из палаты мер и весов.

Таблица должна быть одна. И все проблемы сразу исчезнут как по волшебству.

Answer 4

[Vitsliputsli]

Как выкрутиться, чтобы prepare выполнять только один раз?

Prepare подготавливает план, нельзя подготовить план без таблицы.
Тем не менее, prepare будет выполняться 1 раз, но для каждой запрошенной таблицы.

А в чем собственно сложность? Prepared statements это всегда как минимум на 2 запроса больше, чем без них, если просто считать запросы. Хотя колво запросов и скорость не везде зависимы. Да и pdo по-умолчанию предпочитает их не использовать, заменяя своей эмуляцией.

Answer 5

[Артур]

раздели на модели

<?php

namespace app\models;

class Limits extends \app\base\Model {
    
    public $table = 'db_limits';
    
    public function getLimits($lim = 1) {
        $sql = "SELECT * "
                . "FROM {$this->table} "
                . "ORDER BY id DESC "
                . "LIMIT {$lim}";
        return $this->findBySql($sql);
    }
	
	public function updateCurrs($a,$b,$id=1) {
		$sql = "UPDATE {$this->table} SET $a = '$b' WHERE id = ?";
        $this->query($sql, [$id]);
    }

}

Comments

[Ипатьев]

А зачем в этом коде SQL инъекции?

[Артур]

Ипатьев, ну да ну да это же самодостаточная часть без подготовки. Это код с проекта экономической деятельности, с обкаткой более 7лет и никому не удалось. Хочется попробовать - велком

[Ипатьев]

При чем здесь какая-то экономическая деятельность? Речь про код. Который весь состоит из инъекций. И который должно быть стыдно выкладывать на люди. Не говоря уже о том, чтобы так жалко оправдываться, показывая, что вы за 7 лет так и не научились писать безопасный код, и до сих пор считаете, что так и надо.

[Артур]

Ипатьев, еще раз знатно просмеялся :)
'При чем здесь какая-то экономическая деятельность?' - при том что админы крутят весомые кассы и такие проекты как лакмусовая бумажка для ломателей-онлайн :)
К слову пофыркать каждый может приведите свой аналог, дабы отстоять позицию - 'фу, вы говнокодер'.

[Ипатьев]

Опять вы почему-то говорите о чём угодно, только не про код. Теперь про каких-то админов.
Вы реально не в состоянии прочесть две строчки кода, которые сюда откуда-то скопипастили?

Речь не про каких-то админов. А про очевидно бессмысленный и небезопасный код, который одно значение передаёт нормально, а второе напрямую в запрос

$sql = "UPDATE {$this->table} SET $a = '$b' WHERE id = ?";
$this->query($sql, [$id]);

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

$sql = "UPDATE {$this->table} SET $a = ? WHERE id = ?";
$this->query($sql, [$b, $id]);

Чтобы быть логичным и предотвращать хотя бы очевидные инъекции. При этом всё оставаясь уязвимым, но это уже второй вопрос.

[Артур]

Ипатьев, тьфу ты про тупо юз плейсов. Данные уже летят подготовленными по функциям и извне на базу прямым образом ничего не идет (ни с get/post/request). Но я уже почитал ваши ответы в темах и понял, что вас хлебом не корми дай слюной побрызгать да в грудь себя бить. Кураторы нынче совсем мелкомягки стали...

[Ипатьев]

Артур, то вы даже не понимаете, что здесь, нет ни ваших ваших "подготовленных функций", ни админов. А только код. Который является однозначно вредоносным (и притом бессмысленным: даже если данные были "подготовлены по фукциям", нет ни малейшего смысла добавлять их в запрос вразнобой, если уж библиотека поддерживает подстановку через плейсхолдеры).

Причём если даже следовать вашей логике (изначально кривой, но сейчас не об этом), то скорее это заведомо целочисленный id может быть "подготовлен" заранее, чем содержимое $b, которое может представлять любое значение для любого поля. Но при этом id попадает в запрос нормально, а $b - нет. Весь этот код - один сплошной анекдот для тех кто понимает.

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

Проблема этого сайта отнюдь не в кураторах.
А в незнайках, которые пишут неграмотный код, и потом вертятся как ужи на сковородке, лишь бы не признавать его кривизну, рассказывая про каких-то админов, перекладывая на них ответственность за свой кривой код :)