Ребят JOIN правильный, но так как у шаблона может быть несколько категорий, выборка идет с дублирующими "ЯЧЕЙКАМИ",в вопросе идет речь про повторы (по умолчанию строк). Из картинок нифига не понятно чего вам не хватает.
operation_type это тип операции. Списание или же начисление. От этого на фронте будет вырисовываться определённый текст. PLUS - начисление, SUB, списание, но как я уже и сказал это у меня вызывает вопросы. Ведь даже при списании будет начисление.Смысл? Правильнее добавлять минус при списании к стоимости покупки, тогда это поле вообще не понадобится, а сумма по транзакциям будет правильной. Ну и на фронте исходя из знака отображать что там нужно...
list_purchase, конечно можно вынести в отдельную таблицу и я понимаю даже почему, но данное поле даже необязательное, оно как примечание. Стоит ли для неважный вещей создавать таблицу?Вообще странно, что у вас покупка состоит вроде бы из набора итемов, но они нигде не перечислены, кроме как в необязательном поле...
Не будет ли нарушаться принцип KISS?KISS это не принцип построения структур, это принцип построения кода, понятного для чтения и интерпретации. А изначально вообще принцип построения визуальных интерфейсов. В построении структуры реляционных баз основной принцип - соблюдение нормальных форм (см. ниже).
И как бы Вы реализовали систему списания и начисления баллов? Наверное это самый главный вопросТак а какая логика начислений? Надо добавить - делаем апдейт на нужную сумму, нужно списание - делаем апдейт на нужную разницу, в чем вопрос?
Стоит ли делать зависимости? Чтобы сумма бонусов клиента зависела от таблицы покупокЭто называется "нормальные формы". На практике вам будут нужны первая, вторая и третья нормальная форма (например хранение total_purchase нарушает 3 НФ, так как может быть вычислена из объединения с таблицей покупок).
Может где то, в определённом источнике имеется свод информации, касаемо таких решений? Может где то, в определённом источнике имеется свод информации, касаемо таких решений?
SET GLOBAL auto_increment_increment=10;
SET GLOBAL auto_increment_offset=1;
ALTER TABLE example DROP COLUMN id;
ALTER TABLE example ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT, ADD INDEX (id);
Вообще задача странная, и попахивает очередным "гениальным" решением... $q = "INSERT INTO post(author, date_p, text_p) VALUES ('$author', '$datep', '$text_content')";
// ";" в одиночных запросах не ставится, а текстовые значения обрамляются кавычками
var_dump($q); //смотрим глазками, проверяем в консоли
$q = "INSERT INTO post(author, date_p, text_p) VALUES (?, ?, ?)";
//никогда не лезем в бд без подготовленных выражений!
$st = $pdo->prepare($q);
$sth->execute([$author, $datep, $text_content]);
SELECT DISTINCT tt.term_id
FROM wp_term_relationships AS tr
JOIN wp_term_taxonomy AS tt
ON tr.term_taxonomy_id = tt.term_taxonomy_id
JOIN wp_terms AS t
ON tt.term_id = t.term_id
WHERE tr.object_id IN (
SELECT p.ID
FROM wp_posts AS p
JOIN wp_term_relationships AS tr
ON p.ID = tr.object_id
JOIN wp_term_taxonomy AS tt
ON tr.term_taxonomy_id = tt.term_taxonomy_id
JOIN wp_terms AS t
ON tt.term_id = t.term_id
WHERE p.post_type = 'product'
AND p.post_status = 'publish'
AND tt.taxonomy = 'product_cat'
AND t.term_id = '2961'
)
AND tt.taxonomy LIKE 'pa_%';
SELECT m.*, u.login, i.img
FROM messages m
LEFT JOIN users u
ON m.to_user_id = u.id
LEFT JOIN image i
ON m.to_user_id = i.obj_id
WHERE m.date > :lastdate # надо выбирать все что позже уже полученных сообщений
AND image.obj_type = 'user'
AND m.from_user_id = :fid # айди "от юзера"
AND m.to_user_id = :tid #айди "к юзеру"
ORDER BY m.date # по возрастанию все старше последнего полученного
Как теперь массово выдать монеты этим пользователям через mysqli ?Ну так откуда нам знать? Что за таблица, что и как там храните? Вообще понятие "массово" вставить разнородные данные может подходить только к инсерту, апдейт в вашем случае делается единично каждой записи по условию совпадения поля. Внутри вашего форича после получения данных и делайте апдейт.
if(isset($submit))
А если я не нажал кнопку, просто нажал ентер в любом поле?$number = $_POST['phone_number'];
Такого поля в форме вообще нет.if(isset($name) && isset($email))
Ну допустим есть такие переменные, если в них не нэйм и емэйл то что делать? С мессажем та же фигня...Как мне сделать , чтобы бэк сам послал запрос в базу данных в это времяНикак, в это время будет каждый раз разное, и даже если использовать крон с какой-то долей разумности, отследить конкретно это время не получится, но это и не нужно...
в посте есть еще пункт статус, который будет меняться на false,Зачем? Разве не понятно что текущее время больше даты окончания?
Как такое лучше всего реализовать?Тупо проверяйте время окончания, и стройте логику вывода исходя из него.