Boris Köln

Столбец book_name является названием таблицы

На чистом SQL подменить имя таблицы не получится.

Вариант 1. Использовать любой ЯП (например, PHP): первым запросом получить данные, из них построить второй запрос.

Вариант 2 (говнокод). Одним SQL-запросом всегда left-джойнить все возможные таблицы и потом с помощью IF брать данные из нужной.

Вариант 3 (правильный): спроектировать правильную структуру таблиц.

ru2.php.net/manual/ru/features.file-upload.php

$parts = explode('\\', $class);

Можно (new ReflectionClass($class))->getShortName(), но и так тоже сойдет.

Или все правильно и так и должно быть?

Да

htmlbook.ru/CSS/Z-INDEX

https://yandex.ru/support/webmaster/yandex-indexin...

https://yandex.ru/referats/

Передавайте один параметр - ассоциативный массив. И потом из него по ключу берите нужное значение.

Вариант 1 (если сайтом уже пользуются).
Писать все warning в лог. Регулярно читать и исправлять.

Вариант 2 (если есть автотесты).
Выводить все warning на экран и исправлять.

Вариант 3.
Воспользоваться статическим анализатором кода. Например, https://plugins.jetbrains.com/plugin/7622-php-insp...

Если это группа магазинов под одной торговой маркой, продающие разные категории товаров (один косметику, другой бытовую технику, третий книги и т.д.), то все в одной БД, юзеры - в схеме public, каждый магазин - в отдельной scheme. По мере роста нагрузки, возможно, придется схемы выносить в отдельные БД/сервера.

Если это разные магазины для разных владельцев - конечно, все в отдельных БД и, возможно, даже на разных серверах.

https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D...

СуммаВыигранныхДенег / СуммаПотраченныхДенег

Права:

$permissions = [
    'manufacturer_order_add',
    'manufacturer_order_view',
    'manufacturer_order_edit',
    'manufacturer_order_drop',
];

К каждому надо добавить Rule, который будет проверять права (например, проверить статус заказа и что его автор - текущий юзер).

Проверка:

$user->can('manufacturer_order_edit', ['order' => $order])

Подробнее см. www.yiiframework.com/doc-2.0/guide-security-author...

Вариант 1 (очень неэффективный, ибо будет N+1 запросов):

SELECT title, likes, (num + likes) AS sum_likes FROM
(SELECT title, ... AS likes FROM posts) t
ORDER BY sum_likes DESC

Вариант 2:

SELECT posts.title, likes.cnt, posts.num + likes.cnt AS sum_likes
FROM posts
LEFT JOIN
   (SELECT post_id, COUNT(id) as cnt FROM likes GROUP BY post_id) likes
   ON posts.id = likes.post_id

Но при большом (около тысячи запросов) обращение к коду, получается что Показывает довольно часто.

Капитан Очевидность подсказывает, что из 1000 запросов при вероятности 1% будет в среднем 10 "показать" и 990 "скрыть".

Причём нужна система выдачи в процентах, т.е. пользователь сам настраивает сколько ему надо

if (mt_rand(0, 100) >= $userOdds) ...

cron

Обычно в браузерах вместо нового окна открывается новая вкладка. Соответственно, размеры игнорируются.

могут ли гарантировать триггеры целостность данных?

В зависимости от уровня изолированности транзакций.