alexalexes

Если это MySQL, сразу после подключения есть запрос на выбор БД (use ваша_база), его нельзя проигнорить и начать выполнять другие запросы, связанные с контекстом таблиц.
Если это другая СУБД, то выбирается по умолчанию схема данных та, которая закреплена за пользователем по его правам доступа, либо она имеет то же имя, что и логин пользователя.

Сначала выбираете доступные даты:

SELECT distinct P.date
FROM Query Q
JOIN Position P ON Q.id = P.query_id
where P.Date between _ and _

Потом, строите динамический запрос в той среде выполнения кода, где вызывали первый запрос:

SELECT Q.Query,
             QP1.Cnt,
             QP2.Cnt,
             ......
FROM Query Q JOIN Position P ON Q.id = P.query_id
left join (select Q1.Query, P1.Date, count(*) as Cnt from Query Q1 JOIN Position P1 ON Q1.id = P1.query_id group by Q1.Query, P1.Date) QP1 on QP1.Query = Q.uery and P1.Date = P.Date
left join (select Q2.Query, P2.Date, count(*) as Cnt from Query Q2 JOIN Position P2 ON Q2.id = P2.query_id group by Q2.Query, P2.Date) QP2 on QP2.Query = Q.Query and P1.Date = P.Date
....
where P.Date between _ and _
    and (QP1.Cnt > 0 or QP1.Query is null)
    and (QP2.Cnt > 0 or QP2.Query is null)
    ....

Строк в каждом секции с ... должно быть столько, сколько дат.

У вас нет связи между таблицами Orders и Products.
Либо потеряли свойство, для обеспечения связи "один-ко-многим":
(Если один заказ может содержать в себе строго один продукт)

CREATE TABLE Orders (
...
Product_Id int,
FOREIGN KEY (Product_Id) REFERENCES Products(Product_Id) -- внешний ключ к продуктам
...

Либо потеряли целую таблицу, для обеспечения связи "многим-ко-многим":
(Если один заказ может содержать в себе много продуктов)

-- Таблица "Позиция продукта в заказе"
CREATE TABLE Order_Positions (
position_id INT PRIMARY KEY,
order_id INT,
product_id INT,
FOREIGN KEY (Product_Id) REFERENCES Products(Product_Id), -- внешний ключ к продуктам
FOREIGN KEY (order_id) REFERENCES Orders(order_id) -- внешний ключ к Заказам
);

Проектируйте структуру базы данных так, чтобы сохранялась полная история действий над каждым классом данных, словно сохраняете лог для спец. служб.
Api пользователя не должно использовать DELETE, только INSERT, и UPDATE только для выставления даты удаления записи, выставления метки последней актуальной записи истории. Операцию DELETE имеет право использовать только служебный метод для зачистки истории, когда устаревшие записи становятся неактуальными ни для одного актора системы.

Если задача на знание справочника SQL, то есть такая конструкция:
таблица1 join таблица2 using (общие_имена_полей)
это эквивалент:

таблица1 join таблица2 on таблица1.общее_имя_поле = таблица2.общее_имя_поле...

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

Что-то много философии про можно/нельзя. Нужно влоб погуглить "join-ы в sql" и набросать что-то такое:

select b.*, -- все колонки по книге
        a.* -- все колонки по сведениям об авторе
from books as b
join book_autor as ba on b.book_id = ba.book_id  -- если у книги может не быть авторов, то нужен left join
join autors as a on ba.autor_id = a.autor_id -- если у книги может не быть авторов, то нужен left join
where b.book_id = :book_id -- сюда подставляем параметр нужной книги.

В реляционной базе - основная таблица - это лог событий.
event_log:
event_id - идентификатор события
event_date - дата и время события
event_type_id - тип события (пришло или ушло)
value - сколько (пришло или ушло, положительное значение)
А чтобы подготовить данные для визуализации, переводите лог в агрегированный вид:
либо делаете view на основе запроса, либо делаете хранимую процедуру для генерации агрегированных данных и кладете их в отдельную таблицу:
daily_statistics:
id - идентификатор агрегированной точки
stat_date - дата агрегированной точки
in_value - пришло (кол-во)
out_value - ушло (кол-во)
current_value - баланс

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

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

select t1.*, -- тематики
      t2.* -- вопросы
from table_1 t1
join table_1 t2 on t2.topic = t1.id
where t1.topic is null
and t1.Name like 'Тематика%' -- не хватает атрибута type, чтобы различать раздел от тематики

Составить SQL-запрос на основе синтаксиса WITH RECURSIVE, чтобы выборка происходила от корня к листьям.
Выполнить запрос и получившуюся выборку прогнать через рекурсивную функцию, которая построит дерево, на основе описанной структуры элемента дерева.

Триггер - это функция (точнее процедура), запускаемая (поджигаемая) событиями изменения данных - insert, update, delete (до или после события), на определенной таблице.
В описании триггера обязательно указано событие, на которое он подписан для начала выполнения.
Обычная функция может быть вызвана как пользователем, так и из тела триггера.
Триггеры, функции, процедуры как правило пишутся процедурным языком, встроенным в СУБД, в отличии от декларативного языка SQL.

Структура таблицы нормальна, только добавьте индекс на поле date_submitted и индекс на поле score и будет летать.
Запрос для получения рейтинга на каждый день для всех пользователей будет примерно такой:

with date_list as (/*Любым способом получаете непрерывный список дат интересуемого диапазона */)
select A.date, u.user_id, nvl(A.max_score, 0) max_score /* nvl зависит от СУБД */
from (select dl.date, u.user_id, tb_max_score.max_score,
          rank() over (partition by dl.date order by random() /*реализация функции random зависит от СУБД*/ ) rnk
from (select us.date_submitted, max(us.scope) max_score
           from user_score us) tb_max_score  -- выясняем макс-ные баллы
left join date_list dl on dl.date = tb_max_score.date_submitted
left join user_score us on dl.date = us.date_submitted  -- выясняем, у кого макс-ные баллы
                                  and us.score = tb_max_score.max_score
) A
cross join user u u.user_id = A.user_id -- прицепляем тех, кто возможно не участвует в рейтинге
where A.rnk = 1

Можно, через join этих двух таблиц.
Результатом запроса будет выборка:

(product_)id, (product_)name, (photo_)id, (photo_)url
1, 'Товар 1', 1, 'example.png'
1, 'Товар 1', 2, 'example2.png'

На стороне скрипта, который отправлял запрос SQL в СУБД, собираете на основе этой выборки объект с требуемой структурой, и потом перекодируете его в строку JSON.

Оборачиваете html-таблицу в форму, с кнопочкой сабмита. Когда отметили нужное, пользователь должен засабмитить форму. В форме нужно указать метод передачи GET или POST и адрес, где будет располагаться серверный скрипт обработки формы.
В скрипте примерно такой код:

<?php
// считаем, что данные пришли по POST-у
if(isset($_POST['submit'])) // проверяем, что приехали данные формы по submit, в кнопке сабмита атрибут name должен иметь значение submit
{
   $inserted_user_count = 0;
   if(isset($_POST['selected_users'])) // присутствуют отмеченные пользователи
   {
      $pdo = new PDO(параметры подключения к базе);
      foreach($_POST['selected_users'] as $selected_user_id)
      {
        $stmt = $pdo->prepare('insert into ваша таблица (атрибуты таблицы) values (значения атрибутов таблицы, кроме user_id, :user_id)');
        $stmt->bindParam(':user_id', $selected_user_id, PDO::PARAM_INT);
        // еще байндим какие-то параметры у запроса, если есть плейсхолдеры, кроме :user_id.
        $stmt->execute(); // наконец, выполняем запрос
        $pdo->commit(); // фиксируем изменения в базе данных, если у вас соединение открыто не в режиме автокамита
        $inserted_user_count++;
      }
      $pdo = null; // закрываем соединение с базой
   }
   echo 'Обработано пользователей: '.$inserted_user_count;
}
?>