Adamos

Я бы при обращении к этому ajax-файлу выдавал следующее:

$result = [
  'tasks' => [
    1 => ['title' => 'Собрать монеты', 'desc' => 'Подробное описание'],
    2 => ...
  ],
  'awards' => [1 => 'Серебро', 2 => 'Золото', 3 => 'Чугун'...],
  'prizes' => [[1, 1], [2, 2], [2, 1]...]
];

И собирал нужные данные в кучку уже джаваскриптом на клиенте. Чтобы:
1) не гонять хренову кучу без толку дублирующейся информации между базой и пыхом и между сервером и клиентом;
2) получать первые два списка тупо из кэша БД, потому что никакие хитрые выборки в этой ситуации на хрен не нужны.

А что, первые шесть пунктов уже удалось успешно "нарушать"?
Седьмой пункт не имеет смысла, если вы собрались просто лечь с учебником на диван.
Он предполагает, что вы, осилив предыдущие шесть, готовы написать полноценное приложение.
И, если оно будет использовать какие-то незнакомые вам технологии - попутно их изучить.

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

Это вообще не SQL-запрос. Это ваша фантазия на тему, как писать на SQL.
Пройдите какие-нибудь бесплатные курсы типа sql-ex.ru хотя бы.

Стандартный треш, пригодный только для корзины.
Читайте про нормализацию БД.

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

Рендер выключил музыку
"Полное описание системы ... займет не менее шести солидных томов — на немецком", — решил он.

Пишешь на PHP обобщенный вывод данных из запроса в HTML-таблицу.
Если нужен xls - добавляешь HTML-заголовок с кодировкой, отдаешь этот файл с заголовком, в котором сказано, что это xls-файл, любой офис это спокойно воспринимает.
Если нужен pdf - скармливаешь ту же таблицу mPDF. Десяток строчек кода.
Вот и асе.
Главная трудность в том, чтобы выдавать корректные заголовки столбцов таблицы.
Но это за вас никакая сторонняя библиотека все равно не сделает - откуда ей знать, что у вас за данные?

На самом деле, DATEDIFF вам совершенно ни к чему. Нужно всего лишь вычесть год рождения из текущего, а затем уменьшить результат на единицу, если месяц рождения больше текущего или месяцы равны, а дата больше.
Можно свести это к одной формуле год * 10000 + месяц * 100 + день.
Нацело делим разницу на 10000 - получаем возраст.

1. получаем баланс пользователя из базы
2. проверяем хватает ли средств для перевода по полученному балансу в пункте 1
3. обновляем значения у одного пользователя и другого в базе

Вообще-то эти действия при желании выполняются одним атомарным запросом UPDATE ... JOIN ... WHERE.
После которого можно проверить, сколько строк изменил запрос - и либо сохранить информацию об успешно совершенной транзакции (у вас же не только сумма на счетах меняется, правда?), либо вернуть ответ о невозможности перевода.

select `id`, `title`, `slug`, `label`, `price`, `old_price`, `category_id`, `picture_id`, `brand_id` 
from `products` where 
`brand_id` IN (select id from `brands` where `title` like '%лампа%' or `tags` like '%лампа%') 
OR `title` like '%лампа%'
group by `products`.`id`
order by `products`.`sales` desc, `products`.`views` desc 
limit 18

Начинаете транзакцию.
Обрабатываете строки.
По тому же условию обновляете строки.
Завершаете транзакцию.

Это, на самом деле, будет проще и надежнее любых хитро составленных запросов.

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

Не стоит мешать код и верстку. Рано или поздно все равно дойдете до их разделения, лучше рано. Сначала весь PHP: подготовьте все данные, которые будут выведены. Потом пошла страница с минимальными вставками уже подготовленных данных. Максимум допустимой логики - вывод данных в цикле.

Если у вас тяжелые внешние ссылки, сделайте ленивую загрузку. Хотя бы элементарно - выводите страницу со всей версткой, но без конкретики, а в конце пишите javascript, который назначает конкретным картинкам конкретные src. Это несложно, правда. Впрочем, если для этого познакомиться хотя бы и с общеизвестным JQuery, все станет еще проще...

Обычное решение - JOIN таблицу саму с собой ON idUsr и date(time) равны, а id разные.

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

Даже без JOIN (мало ли, какие-то данные могут быть многострочными) совершенно необязательно городить циклы.
Вы запросили статьи. Получили данные. Зачем сразу выводить? Соберите их пока в массив, попутно создавая массив id статей, авторов, чего там еще понадобится.
Следующим номером сделайте один (!) запрос - SELECT author_name FROM authors WHERE author_id IN (у нас уже есть этот массив). Аналогичный запрос или два к таблице с комментариями - и все, больше вам базу дергать не требуется, и все данные для вывода получены.

Глядишь, понемногу придет осознание, какую пользу приносит разделение логики и вывода...

REAL описывается не одним размером, а двумя - сколько цифр всего и цифр после точки.
REAL(10,2) - например.
Собственно, для цен логичнее использовать специально для них созданный DECIMAL. С аналогичным описанием.

sql-ex.ru