Akina

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

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

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

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

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

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

При этом по факту я спокойно вставляю в таблицу произвольную строку и никакой проверки не происходит, данные спокойно записываются в таблицу.

Произвольный текст, не содержащий тегов, является валидным содержимым, но не XML документом. Не-XML фрагмент игнорируется при проверке.

Попробуйте вставить нечто, являющееся документом/фрагментом XML, но с ошибкой в разметке - тут же схлопочете ошибку.
DEMO

В матрице Z(0..m, 0..n) элемент X(a,b) является соседом элемента Y(c,d), если выполняются условия

((a-b) MOD (m+1)) входит в {0, 1, m}
((c-d) MOD (n+1)) входит в {0, 1, n}

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

PS. MOD - оператор получения остатка от целочисленного деления.

Данные поступают на один из серверов кластера. Оттуда они распространяются/реплицируются на остальные серверы кластера. Очевидно, что процесс передачи на другие серверы - не мгновенный, и требует некоторого времени. И столь же очевидно, что если после получения новых данных, но до передачи их в другие серверы кластера исходный сервер сдох, то этих данных не будет на оставшихся серверах, и, как Вы правильно заметили, запросы будут выполняться с устаревшими данными.

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

Хотим открыть общий доступ к файлам Microsoft Office по сети, чтобы пользователи могли редактировать, но не удалять файлы.

Ставим сетевую корзину (программа третьей стороны, практически любая подойдёт, лишь бы запоминала, кто удалил). Удалённый файл, в отличие от обычной процедуры в Windows, не уходит в никуда, а помещается в сетевую корзину.

Если туда попал именно окончательно удалённый файл (а не удалённый в связи с созданием новой версии) - восстанавливаем, а потом находим виновного и выписываем ему крепких и качественных звездюлей. Без последнего этапа схема практически не работает - как удаляли что не надо, так и будут удалять..

Для решения задачи набор искомых значений должен быть (синтетическим) набором записей, который используется в источнике данных запроса.

Если монитор имеет опцию PiP (картинка в картинке) либо PbP (картинка рядом с картинкой) - то вообще без проблем. Иначе - переключение через меню монитора или, как сказал Stalker_RED, командами DDC.

Ещё вариант - подключить монитор только к одному из компов, и с него же подключиться к удалённому рабочему столу второго компа. Правда, при этом необходимо, чтобы компы были объединены сетью.

1. Каждый DHCP-скоп должен "сидеть" в своём VLAN. Так что VLANID=10 для DHCP-сервера - явно неправильно. Он должен раздавать адреса юзерам и, возможно, принтерам, так что два скопа и три VLANID (ибо он сервер и должен быть в VLAN серверов). Да, серверы с динамическим IP - это более чем странно, даже при статическом резервировании.

2. Клиентских портов - да, не требуется. А вот на транке добавь, хуже не будет.

3. Аналогично - лучше добавь.

4. Можно и так, и эдак. Как по мне - принтсервер таки сервер, вот и пусть его в сегменте серверов. А вообще я б его делал двухинтерфейсным, наверное - один в серверах, второй с принтерами, так ему проще будет отлавливать включение-выключение принтеров.

5. Так принт-сервер и его очереди же публикуются через домен, а доступ к нему маршрутизируется. Зачем тебе прямой доступ клиентов к принтсерверу?

Нет такого понятия - "роутер создаёт подсеть". Подсеть просто существует - потому что может. А любое оборудование (в том числе и роутер) либо узел в этой подсети, либо нет. Либо, при ошибке настройки, попадает в эту подсеть, но из-за несовпадения маски функционирует частично неправильно.

Навскидку:

1. Звезда - плохо. Случись что, и сегмент отвалится. Я бы делал как минимум кольцо, и в него ERPS или RSTP (ещё лучше - кольцо на ERPS, а дальше RSTP). Ещё лучше - два кольца. И из тех же соображений надёжности - минимум два магистральных коммутатора на площадку/здание.
2. Неуправляемые коммутаторы - забудьте как страшный сон. Например, надо перестартовать камеру по питанию - что, бежать к камере? да даже элементарно посмотреть статус коннекта... ставьте PoE L2.
3. Транки я бы делал 10G.
4. Оптический коммутатор в центре достаточно L2 или L2+. У него вообще все порты будут в транке (tagged).
5. По части подсетей - для указанного количества оборудования я бы брал подсети /23 или /22 из 172.16. Избыток адресов ни на что не влияет, а их недостаток - это по определению геморрой. Оно надо?
6. Если подсеть исчерпала адреса - то перестраиваешь DHCP-сервер, раздающий адреса. Либо расширяешь подсеть, либо добавляешь ещё один скоп и организуешь маршрутизацию. Второе правильнее - ибо в любом сегменте найдётся оборудование со статическим назначением адресов (не статическое резервирование!), при изменении маски их придётся перенастраивать.
7. И я как-то не увидел управляющего VLAN, в котором будут только административные адреса коммутаторов.

Ну вариант первый - это просто хранить данные за день, а всякие укрупнения считать в момент необходимости.

Вариант соответственно второй - считать все укрупнёнки в момент записи текущих данных. Удалять/чистить лучше отдельной эвент-процедурой, если старая укрупнёнка недельку полежит, никто не помрёт. Вопрос отдельных таблиц под разные укрупнёнки - только если их структура различна в зависимости от периода, иначе одна таблица и поле маркер - диапазон периода записи.

Условие пересечения диапазонов: начало любого диапазона меньше конца другого диапазона.

(x < b) AND (a < y)

Условие непересечения: начало какого-либо одного диапазона больше конца другого.

(x > b) OR (a > y)

Если касание допустимо - использовать нестрогие неравенства.

При добавлении набора данных в связанные таблицы (а по большому счёту - вообще всегда) следует забыть о существовании INSERT .. VALUES и пользоваться исключительно INSERT .. SELECT. Первый запрос вставляет запись в основную таблицу, второй вставляет в зависимую, получая необходимое для связывания значение из основной по известным критериям отбора (по только что вставленным значениям, либо, в случае MySQL, из LAST_INSERT_ID).

Демонстрация метода замены вставки на обновление: fiddle.

ОШИБКА: в целевой внешней таблице "users" нет ограничения уникальности, соответствующего данным ключам

Ошибка указывает на проблему, связанную со следующим внешним ключом:

FOREIGN KEY(user_id) REFERENCES users (user_id)

Таблица users должна существовать.
В ней должно существовать поле user_id.
Это поле должно быть определено как уникальное. Причём отдельно, а не в составе композитного уникального индекса.

Так что смотрите, что именно нагенерила модель.

PS. Если определено PRIMARY KEY (user_id), то дополнительное UNIQUE (user_id) абсолютно бессмысленно.

Нормально спроектированная СКС предполагает как минимум наличие одного центра. Там собственно и размещается общее оборудование. Для настолько малой сети - стойка/шкаф, туда маршрутизатор доступа в Инет, коммутаторы, патч-панель и бесперебойник, и туда же заводится линк к провайдеру. От патч-панели - разводка медью до точек подключения стационарных компов (с пробивкой в розетки, предусмотреть лотки для раскладки кабельной сети), точек доступа и периферии.

Коммутаторы - достаточно одного на 24 клиентских порта для разводки по меди (хотя раскладку всегда следует делать с запасом, народ то мебель переставит, то сетевую МФУ купит, то ноут подключит кабелем, так что я бы взял на 48 портов) и одного PoE на 8 портов для подключения точек доступа.

Маршрутизатор - если нет необходимости разграничивать доступ, то формально и какого-нибудь SOHO роутера хватит. Скажем, Микротика из недорогих..

Точки доступа лучше брать сразу комплект под бесшовку, чтобы с настройкой не трахаться. А если управляющий корпус сам обеспечивает PoE, то и второй будет коммутатор не нужен.