Akina

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, то и второй будет коммутатор не нужен.

Вы неправильно понимаете, и от того неправильно мыслите.

Представим, что у нас на коммутаторе сделаны, скажем, 3 VLAN. Ну и подключены какие-то узлы-клиенты. Так вот - чтобы построить то же самое, но без управляемого коммутатора, Вы должны взять три отдельных коммутатора, и в соответствии с VLAN переключить на них всех клиентов.

Иными словами, сети различных VLAN изолированы друг от друга ПОЛНОСТЬЮ. И пусть Вас не обманывает, что все они сходятся в одном коммутаторе - внутри этого коммутатора никакого соединения между VLAN нет. Соответственно чтобы трафик ходил из одного VLAN в другой, нужен маршрутизатор, который одним интерфейсом смотрит в один VLAN, другим - в другой VLAN.

Вы хотите сделать у себя 5 VLAN. Соответственно если они, скажем, должны обращаться к одному и тому же серверу-файлопомойке, или через этот один сервер ходить в Интернет, значит, в этот сервер придётся вставить 5 сетевых карт, и каждую из карт подключить к отдельному порту коммутатора, являющемуся членом одного из имеющихся VLAN. Вот Вы точно этого хотите? А представляете, какой получится монстр, если количество VLAN будет не 5, а 15?

Да, в именно описанном случае можно спасти ситуацию, если использовать серверное оборудование и ПО, которые могут на одном внешнем интерфейсе создать несколько адресов из разных подсетей и статически зафиксировать для каждого из адресов определённый МАС-адрес, а на коммутаторе включить МАС-based VLAN. Но, поверьте, Ваша ситуация ну совершенно не располагает к созданию себе подобного геморроя...

--------------------

Как по мне, Вам вполне достаточно просто сделать несколько подсетей.

1. Подключаем к розетке комп/ноут.
2. Подключаемся к коммутаторам, смотрим FDB, ищем МАС компа/ноута на клиентском порте.

Альтернативное решение.

1. Подключаем к розетке комп/ноут.
2. Запускаем от имени администратора следующий батник:

:start 
netsh interface set interface "Имя сетевого интерфейса" disable
timeout /T 3
netsh interface set interface "Имя сетевого интерфейса" enable
timeout /T 3
goto :start

Идём по коммутаторам и ищем клиентский порт, мерцающий с частотой раз в 3 секунды.

SELECT *
FROM tablename, 
ORDER BY column3 = 'какое то условие' DESC,
         column2 = 'какое то условие' DESC,
         column1 = 'какое то условие' DESC

Запрос предполагает, что columnX не содержит NULL.

если в данной таблице уже существует поле с данным товаром, то прибавить единицу к его количеству
а если его вообще нет, то создать новое поле

??? Какое ещё "поле"? может, запись? ну так для этого существует INSERT ... ON DUPLICATE KEY UPDATE Statement.
А триггеры - они для дела, а не для баловства..

Скопируйте данные из 2-4 файлов на листы 2-4 книги 1 (или сразу листы целиком). Можно и не копировать, но так проще, не надо держать открытыми 4 книги, да и финальная конструкция получается переносимой.
Используя ВПР(), в дополнительные колонки на листе 1 скопируйте данные с листов 2-4.
Окончательно в дополнительных колонках на листе 1 с помощью ЕСЛИ + ЕПУСТО/ЕНД соберите из 4 значений одно финальное для каждого атрибута.
Замените формулы на значения.
Удалите промежуточные колонки.
Всё.

Пример для 4 книг, без копирования. Приоритет - 1,2,3,4.

MS Access не имеет функции групповой конкатенации.

Проблема решается путём создания пользовательской функции и использования её в запросе.

Function group_concat(category As String) As String
With CurrentDb.OpenRecordset("SELECT [Цех] FROM [Имя таблицы] WHERE [Продукция] = '" & category & "'")
    group_concat = ""
    .MoveFirst
    While Not .EOF
        group_concat = group_concat & "," & ![Цех]
        .MoveNext
    Wend
    .Close
End With
group_concat = Mid(group_concat, 2)
End Function

Поскольку пользовательская функция - скалярная, и не агрегатная, её нужно оборачивать какой-либо агрегатной функцией.

SELECT [Продукция], MAX(group_concat([Цех])) AS [Цех]
FROM [Имя таблицы]
GROUP BY [Продукция];

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

---
Ну или взять готовую DConcat() от Patrick G. Matthews: https://www.experts-exchange.com/articles/2380/Dom...