FanatPHP

Как правильно отметили выше, тебе не нужна "ручка для 8 класса": WHERE 1 в PDO работает точно так же.

Другое дело, что все можно сделать гораздо проще, и без where 1, и без кучи условий (представь свой код, если в запросе будет участвовать не два поля, а три). На самом деле условий нужно не больше, чем полей в запросе:

if (!empty($foo1)) {
    $where = "foo1= :foo1";
    $placeholders[':foo1'] = $foo1;
}
if (!empty($foo2)) {
    $where = 'foo2 = :foo2';
    $placeholders[':foo2'] = $foo2;
}
$sql = "SELECT type FROM tablepart";
if ($where)
{
    $sql .= " WHERE ".implode(" AND ", $where);
}
$stmt = $pdo->prepare($sql);
$stmt->execute($placeholders);
$data = $stmt->fetchAll();

Объясняю:
Это не "PDO имеет подключение", а пользователь БД имеет доступ.
Если указанный при подключении пользователь имеет доступ к некоторой БД, то мы можем выполнять запросы к ней.

Отсюда можно сделать вывод: Если указанный при подключении пользователь имеет доступ к обеим БД, то такой запрос никакой не извращение, а совершенно стандартный SQL.
Если же доступ есть к только одной БД, то запрос не пройдет. Опять же, не из-за своей нестандартности, а по банальной причине отсутствия доступа.

А уж чрез PDO ли мы подключаемся, или через консоль - это уже без разницы.

Могу ответить за PDO.

1. PDO не имеет никакого отношения к запросам. ПДО не пишет за тебя SQL и не делает его безопасным. Можешь называть колонки как угодно, ПДО это до лампочки.
2. Чтобы обезопасить данные, надо использовать **подготовленные выражения.**

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

Типичный карго-культ код, в котором присутствует куча бессмысленных телодвижений и отсутствует то что действительно нужно.

Как это должно выглядеть на самом деле:

public function countOrders($user_id)
{
      $stmt = $this->pdo->prepare("SELECT count(1) FROM orders WHERE user_id =?");
      $stmt->execute([$user_id]);
      return $stmt->fetchColumn(); 
}
// и использование
echo $obj->countOrders($_SESSION['user_session']);

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

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

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

- куча времени, убитого на поиски, адаптацию, и допиливание означенного автопостроителя
- эмоции вида "как эта №%;%:?У#$^№ вообще работает??!" когда через пол-года придется добавить какое-либо новое поле
- апофеоз, когда потребуется добавить условие, не поддерживаемое автопострителем, какое-нибудь IF EXISTS

Поверьте, затраты на написание запроса вручную (неважно, через убогое mysql_query или Доктрину) - ничто по сравнению с возможностью **прочитать и понять**, для чего, вообще, данный код нужен, и как он это делает.

Поэтому излишняя автоматизация бывает очень вредна. И гоняться за ней не стоит.

Синтаксис SQL не отличается ничем.
Отличается только способ подстановки переменных.

Во-первых, запросы должны исполняться не через mysql_query, а через PDO
В-вторых, на месте переменных должны стоять знаки вопроса, а сами переменные - передаваться в запос при исполнении:

$stmt = $pdo->prepare("UPDATE `users` SET `name`=? WHERE id=?");
$stmt->execute(array($name, $id));

• REST
  
• SOAP
  
• JSON-RPC <- рекомендую. так называется то, что коряво советуют остальные
  

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

ON DUPLICATE KEY - вполне определенный тип запроса, и использование его для мультиапдейта - хак, чреватый непредсказуемым поведением (например, возвращением в строй уже удаленных записей).
Но похапе программисты, однажды узнав о таком "лайфхаке", начинают страшно гордиться таким сокровенным знанием" и пихать его по делу и без дела.

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

> Можно это как-то реализовать средствами MySQL, не убирая переменную из строки SQL запроса?
Нет.
По-любому строку запроса модифицировать придется.

Другое дело, что совсем не обязательно это делать руками.
Если пользоваться хотя бы минимально интеллектуальными средствами для работы с БД, а не шарашить по-старинке пещерными методами из прошлого века, то такая проблема попросту не возникает. К примеру, любой ОРМ решает ее по умолчанию.

Если никак не получается расстаться с SQL, то safemysql подойдет лучше всего.

$data = array_filter($data); // уберём пустые поля нафиг
$db->query("INSERT INTO ?n SET ?u", $table, $data);

Для остальных либ принцип тот же, но придется повозиться с передачей переменного числа параметров

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

P.S. На текущий момент необходимо вырезать гланды.

SELECT * FROM sites LEFT JOIN users ON sites.id = site_id

Не нужно.
Сколько надо данных - столько и запрашивай, все разом, безо всяких лимитов.

Проблема с пользователем, который экранировал этот запрос.
Для решения проблемы надо отправить пользователя учить правила составления запросов.