$sql .= " LIMIT " . (int)$data['start'] . "," . (int)$data['limit'];
var_dump($sql); exit;
$query = $this->db->query($sql);
Идете в пхпмайадмин или консоль мускуля, вставляете и выполняете. Хотя для начала убедитесь что все вставленные значения хоть как-то похожи на правду.$count_m = "82;
Тут очевидно синтаксическая ошибка сразу. Молчу про то, что числа намеренно передаются строками...if($this->page==1) {
$page = 1;
}
else {
$page = (int) $this->page;
}
Это что за магия? Что оно вообще делает? Что будет если единица ВНЕЗАПНО попадет в блок else??$start = ceil($count_m/$m_per_page);
А теперь подумайте, как должна называться переменная, считающая общее количество страниц.суть в том, что когда формируется limit 72, 24, т.е 3 страница,Стоит пройти курс арифметики за 2 класс, и посчитать что 3 страница будет limit 48, 24.
Можем ли мы сделать запрос к БД и извлечь из промежуточной таблицы (book_author) информацию по конкретной книге?Из "промежуточной" можно извлечь только связи, она для этого и нужна.
Т.е. у нас для работы есть только информация о книге и теперь нужно извлечь информацию о её авторе (авторах).В чем вопрос? Как сделать джоин с 3 таблицами? Так же как с двумя, только с тремя.
Приемлемо ли вообще делать такие запросы к промежуточным таблицам?Какие - "такие"? У вас вообще ни одного запроса не написано.
ini_set('display_errors',1);
error_reporting(E_ALL);
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
Понял что это связанно с htmlspecialchars, но как победить его так и не понял.Во первых - зачем? В смысле какова цель вашей загадочной функции? Почистить строку? Обычно это делается при выводе, а не при записи. Подготовить для вставки в бд? Для этого есть встроенные функции, но и они тут лишние, почему - читай ниже.
Ребят 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);
Вообще задача странная, и попахивает очередным "гениальным" решением...