Дмитрий Энтелис

INSERT INTO `billings` (user_id, billing_type, currency_id)
SELECT
    b.user_id
    ,b.billing_type
    ,c.id as currency_id
FROM (
    SELECT 11 as user_id, 1 as billing_type UNION
    SELECT 11 as user_id, 2 as billing_type UNION
    SELECT 11 as user_id, 3 as billing_type
) b
INNER JOIN `currency` c ON c.name='usd'

В стиле абстрактного экспрессионизма

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

labs.rampinteractive.co.uk/touchSwipe/demos
www.w3schools.com/jQueryMobile/jquerymobile_events...
www.dejurka.ru/css/swipeable-side-menu

Никак: это не решается стандартными средствами MySQL.
Можно долго и упорно писать многострочные SQL-функции, a можно решить задачу в несколько строк на любом ЯП.

тут несколько моментов:
1. id имеет очень большой приоритет css. объяснить двумя словами тяжело, но вкратце, если вы задали какие-то свойства для id-селектора #x, что ни пишите в классовом селекторе .y, если он подтягивает стили от id-селектора, то они возьмут верх над классовым селектором. Никакие элементы не должны иметь приоритет над другими. Так удобнее редактировать стили.
2. Есть неписанные "законы" БЭМ, которых придерживаются опытные разработчики. Существует много всяких философий БЭМ, самая популярная - яндексовская - погуглите. БЭМ позволяет лучше разбираться в коде, работать с препроцессорами и производить более удобные операции при работе в js.
...ну есть и еще несколько моментов.

Главное отличие id от class в том, что стили id нужно задавать для одного элемента, уникального. А class можно применять для нескольких элементов. Даже если при разработке блок один, никогда не угадаешь, возможно придётся добавлять примерно такой же блок где-нибудь еще на странице - в таком случае id дублировать нельзя - ошибка css.

Вообще, товарищи, используйте id никогда! Class куда удобнее и гибче (хотя бы в том плане, что для одного элемента можно задавать хоть 255 классов одновременно). Придумывались CSS-селекторы в конце 90х годов. Тогда HTML был совершенно на другом уровне, и разработчики смотрели в другую сторону. Им тогда хотелось управлять DOM с помощью JS методом GetElementByID - сейчас этот метод в чистом виде никто не использует. Есть жквери!

1. Собака не имеет никакого отношения к include. Это не один оператор, а два совершенно разных оператора.
   
2. Увидев @ в коде ты можешь почти со стопроцентной уверенностью сказать, что его писал неграмотный пользователь, и пользоваться этим кодом не стоит.
   
3. Увидев в коде @include ты можешь смело считать его автора абсолютным лохом и нубом, а сам код надо выкидывать немедленно. Потому что @include глушит не только саму ошибку включения файла, но и все ошибки в этом файле - то есть, поступает стократ хуже. Это значит, что если автор допускает такие косяки в коде, то и все остальное у него тоже ад кромешный.
   
4. Самое главное. Ошибки надо не подавлять. Ошибки надо исправлять. Но опять же, делать это с умом. Начинающие программисты считают сообщения об ошибках своими личными врагами, и борются с ними всеми доступными средствами - с помощью @, error_reporting(0) и др. Получив линейкой по рукам и запомнив на всю жизнь, что так делать не надо, ониначинают с не меньшим рвением писать всякие проверки - лишь бы не допустить, не дай бог, ненавистного сообщения об ошибке. Например:
   
   

if (file_exists($inc))
{
    include $inc;
} else {
    echo "Файл не найден";
}

Так вот, это - еще хуже. Для начала, часть ошибок этот код все равно не отловит. Но это даже не самое главное. Главное - что вот это вот "Файл не найден" не имеет ни малейшего смысла. Пользователю оно ничего не скажет. А программист о нем не узнает. А если и узнает, то ничего не поймет! Какой файл? Где не найден? По какой причине? Системное сообщение об ошибке содержит массу бесценной информации помогающей идентифицировать ошибку, сообщая нам где она произошла, какой файл не найден, по какой причине не найден. Выдавать вместо этого огрызок "файл не найден" - это мазохизм.

И вот тут мы должны произвести натуральную революцию в неокрепшем детском мозгу: сообщение об ошибке не твой враг, а твой друг! И надо добиваться его появления всеми возможными способами! В том числе и выпиливанием бессмысленных проверок. Проверку можно ставить только если у нас есть сценарий обработки ошибки: к примеру, вместо этого файла мы можем заинклюдить какой-то другой, дефолтный. Тогда да - проверка имеет смысл. Но если это самый обычный инклюд, который всегда должен быть на своем месте, то его отсутствие обязано вызывать ошибку! Чтобы она была сразу показана на дев сервере и тут же исправлена. Чтобы она была записана в лог на продакшене и тут же исправлена.

Ошибки не надо подавлять. Ошибки не надо прятать. Ошибки надо исправлять.