Akina

16 ноутбуков с выходом в интернет. Если подключить к коммутатору, то IP адресов не хватает. Думаю как-нибудь через маршрутизатор подключить, но пока не знаю, как это сделать и какой маршрутизатор для этого подходит. Маршрутизатор будет получать IP адрес от сервера школы.

Иными словами, в качестве маршрутизатора в инет и одновременно DHCP-сервера выступает этот самый "сервер школы".
Соответственно решение - на сервере в настройках DHCP-сервера создать ещё один скоп /27 или шире, и смаршрутизировать его в интерфейс/VLAN, через который подключается коммутатор класса.
Задача должна решаться администратором, а не первым попавшимся под руку неспециалистом.

WITH 
cte AS (
    SELECT * , 
           ROW_NUMBER() OVER (ORDER BY `date` DESC, id DESC) rn, 
           DENSE_RANK() OVER (ORDER BY `date` DESC, id DESC) dr
    FROM `list` 
    WHERE user='1' 
    )
SELECT *
FROM cte
WHERE dr <= (
    SELECT dr
    FROM cte
    WHERE rn = 25
    )

Версия сервера: 5.6.51 - MySQL Community Server (GPL)

SELECT *
FROM `list`
WHERE user='1' 
  AND `date` >= (
    SELECT `date`
    FROM 'list'
    WHERE user='1' 
    ORDER BY `date` DESC, id DESC LIMIT 24, 1
)

1. В сети может быть несколько маршрутизаторов, и разные конечные узлы могут быть доступны через разные маршрутизаторы. Таблица позволяет знать, через кого слать трафик.
2. На компьютере может быть несколько внешних сетевых интерфейсов (а ещё есть localhost), и разные конечные узлы могут быть доступны через разные интерфейсы. Таблица позволяет знать, через кого слать трафик.

Если значение поля с типом TIMESTAMP некорректно (а пустая строка - это некорректное значение) - надо заменить его на корректное.

• Если поле NULLable - то например на NULL.
  
• Если настройки допускают нулевую дату - то на `0000-00-00 00:00:00`.
  
• Иначе - на некое предопределённое значение. В зависимости от смысла поля - либо в далёком прошлом, либо в столь же далёком будущем.
  

Прочитал, что в mysql в движке innodb индексы делятся на два больших типа - первичный и вторичный

Понятия первичного и вторичного индексов никак не связаны с СУБД. И это не типы индексов по большому счёту. Просто первичный - однозначно идентифицирует запись (что определяется ограничениями на значение выражения и используемых в нём полей), тогда как вторичный - всего лишь может использоваться для однозначной идентификации, но лишь при условии, что он отвечает всем требованиям-ограничениям для первичного.

В InnoDB - всего лишь есть дополнение, что при наличии первичного индекса он является также и кластерным. Для других движков и других СУБД такой зависимости может и не быть.

кластеризованный, как написано хранится с данными

Не-а. Кластерный индекс - это когда записи в теле таблицы (т.е. сами данные таблицы) хранятся в порядке сортировки по выражению этого кластерного индекса.

Всегда ли не кластиризованные индексы хранятся в оперативной памяти или это как-то можно регулировать?

Индексы всегда хранятся на диске. В оперативной памяти индексы могут всего лишь кэшироваться. Для ускорения доступа.

Я слышал что индексы должны быть в пределах мегабайт, а не гигабайт.

Или не о том слышал, или не так понял. Индексы никому и ничего не должны по части своего размера, который определяется суммарным размером данных индексного выражения, количеством записей и коэффициентом заполнения.

Читал, что бывает так, что индекс в таблице индекса хранит сразу данные определенных столбцов, а не ссылки на эти строки в основной таблице.

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

Два LEFT JOIN, условие связывания - по id и определённому значению типа.

SELECT *
FROM Author
WHERE NOT EXISTS (
    SELECT NULL
    FROM Book
    WHERE Author.Authorld = Book.Authorld
      AND Book.PublishDateTime >= CURRENT_DATE - INTERVAL 2 YEAR
    )

SELECT table1.*, 
       EXISTS ( SELECT NULL
                FROM table2
                WHERE table2.table1_id = table1.id
                   AND table2.date = @needed_date
                ) AS row_exists
FROM table1

Если точная дата внутри месяца неизвестна, то

WHERE table2.date BETWEEN @needed_month_1st_day AND @needed_month_last_day

• Выделить диапазон с числами.
  
• Alt-F11
  
• Ctrl-G
  
• ввести

  for each onecell in selection:onecell.value="https://d21skl.com/"&onecell.value:next

  
  
• Enter
  
• Alt-F4
  
• Alt-F4
  
  

А решение было близко... раз нужны данные с разных уровней группировки, то либо вертеть подзапросы/CTE, либо использовать оконные функции. Как по мне, второе проще.

SELECT DISTINCT
       product_id,
       size,
       SUM(orders) OVER (PARTITION BY product_id, warehouse_id, size) AS orders,
       FIRST_VALUE(stocks) OVER (PARTITION BY product_id, warehouse_id, size 
                                 ORDER BY `date` DESC) AS stocks,
       warehouse_id
FROM stats
WHERE DATE(`date`) >= '2023-09-01' 
  AND DATE(`date`) <= '2023-09-04';

fiddle

созданы два дополнительных сайта на LARAVEL, с одинаковыми каталогами товаров.

Фраза интенсивно намекает, что эти сайты - полная копия основного. То есть и код, и, главное, структура БД, совпадают с точностью до запятой.

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

Если это по какой-то причине невозможно - то обновление стоимости товаров оформляется в виде необходимых для выполнения операции наборов INSERT/UPDATE/DELETE запросов и выполняется на всех трёх серверах.

Стоимость товаров часто меняется, и менять цены руками на всех сайтах, основном и региональных - трудозатратно.

Если это можно, хотя и затратно, сделать руками - то с точки зрения СУБД это ни разу не "часто", а наоборот - чертовски редко.