djEban, какой смысл рисовать несколько CHECK? Это же однократно вычисляемое выражение, к тому же вычисляемое гарантированно на данных в памяти, т.е. очень быстрое. Впрочем, беды большой не будет...
expr specifies the constraint condition as a boolean expression that must evaluate to TRUE or UNKNOWN (for NULL values) for each row of the table. If the condition evaluates to FALSE, it fails and a constraint violation occurs.
djEban, формально - да. Реально - ну не будешь же ты делать CHECK constraint, чтобы проверять, что в неподходящем поле именно NULL, а не хрень какая значащая, верно? А коли так, то это уже не NULL, а именно игнор.
djEban, а если все данные блока хранить в JSON? Вам же, получается, просто нужно все эти блоки, JSON-объекты, фактически свалить в один массив или объект, ну может с дополнительным уровнем ака раздел да сортированные в некоем порядке - а для этого вполне достаточно какого-нибудь вульгарного json_object_agg(). Если для каких-то надобностей ещё нужны и отдельные свойства - так есть вычисляемые столбцы, не проблема.
Нужно смотреть, как организована эта функция в библиотеке доступа. Потому как библиотека доступа к MySQL просто тупо выполняет сразу после вставки запрос SELECT LAST_INSERT_ID(); - а в постгрессе такой функции немножко нету.
Глеб Старков, нет, не соврал. Правда, есть подвох - при вставке нескольких записей RETURNING в PostgreSQL ведёт себя не так, как LAST_INSERT_ID() в MySQL. Он возвращает набор записей со всеми вставленными ID, тогда как MySQL вернёт лишь одно самое первое сгенерированное значение.
Так это самый обычный МАС-based VLAN. Это - функция на уровне коммутатора, внутри него, и к внешнему WiFi не имеет отношения в принципе. Если не лень прописывать МАС всех камер вручную, и если размера таблицы МАС хватит - то вполне себе решение... правда, при каждом добавлении/перемещении/замене камеры придётся донастраивать, удаляя неактуальные и добавляя новые МАС.
Но отдельный SSID, коммутируемый в отдельный VLAN, куда как проще...
В первой трассе узлы провайдера из диапазона 10.16.248.ххх идут на 3-4 хопах, во второй трассе на 6 хопе. Похоже что у провайдера какая-то непростая схема построения маршрутов, к тому же изрядно перегруженная трафиком (отсюда и отсутствие ответов), и далеко не факт, что там нет косяков. Опять же крайне странно, что не отвечает второй хоп - который дефолтный шлюз у первого роутера.
Полагаю, что если подряд запустить несколько трассировок (для ускорения ограничив маршрут, скажем, 10 узлами), то в каждой трассе будут всплывать то узлы на одних хопах, то на других... и в принципе можно будет собрать всю трассу. Если, конечно, она не станет вилять.
Попробуйте также запустить трассы на DNS провайдера, которые передаются первому роутеру.
Опять же попробуйте те же трассы, но с другого компа. Причём запустите трассы с двух компов параллельно (а если роутер умеет - то и с него), и сравните.
Ещё - загрузите проблемный комп в безопасном режиме с поддержкой сети и посмотрите трассы. Также попробуйте загрузиться и посмотреть с какого-нибудь проверенного LiveCD (2K10, Стрелец и пр.).
Vitalya Ivanov, у вас второй роутер работает в режиме тупого коммутатора.
Если у вас не работает при подключении через второй роутер, но простое перетыкание кабеля из второго в первый восстанавливает доступ, то второй роутер либо неисправен, либо на нём настроена какая-то фильтрация (например, изоляция портов, или что-то в файрволе).
при нагрузке пропадает соединение с интернетом и статус подключения к сети
Я так понимаю, что статус меняется на компьютере, подключенном к роутеру.
Меняется именно статус, или вообще пропадает доступ в Инет?
С интерфейса роутера в этот момент доступ в Инет есть? тупо - пинг куда-нить наружу, а хоть бы и на шлюз и DNS провайдера, имеется?
На каком узле провал? В момент отсутствия Инета - покажите трассу куда-нить наружу.
И выложите лог роутера за период обрыва связи (если лог не ведётся - включите).
Зависит от оборудования - причём не моделей, а конкретных экземпляров. Мой личный рекорд - устойчивые 100 Мбит на 130 метрах. Но по опыту - уже после где-то 80 начинается лотерея.
Без проблем, не заставляю. Но именно такое письмо когда-то сподвигло меня на использование портабельного IMAP4-клиента для выгрузки копии почтовых сообщений, создание копии контактов, копирование всего хранимого на гуглодиске... не на пустом месте я всё это затеял, увы.
К сожалению, самих писем показать не могу - они уже безвозвратно удалены.
А вот "типа такого" - неправильно. CHECK constraint разрешает сохранение записи, если его значение равно TRUE либо NULL:
https://dev.mysql.com/doc/refman/8.4/en/create-tab...
Так что при type IS NULL запись будет сохранена.