никакого объекта для сравнения размеров не предоставлено
Ну почему? пробитая паркетная доска, благо размеры древесного рисунка вполне себе более-менее одинаковы что у них, что у нас, вполне позволяет прикинуть размеры объекта. И ваша оценка размеров вполне адекватна.
Да щазз... Сам лично пробовал - ставлю чисто дрова. Ну так после первой же перезагрузки вылетает баннер "Получить приложение HP Smart". И затрахаешься его отключать.
чтоб печатать много, задёшево и без проблем, досыпая китайский тонер из бутылки?
Вроде Киосеры среднего класса более-менее соответствуют. Только не угробищное 1025-е... мне, например, так и не удалось заставить его сканировать через сеть.
Не, тонер, пусть даже и китайский, должен быть приличным. А не размятая землица из цветочного горшка.
Даже если всё установлено - ему как два пальца потерять принтер при перезагрузке и больше его не найти.
А если не приведи господи у сетевого принтера изменился IP-адрес - вас ждёт увлекательнейший квест по поиску, где в программе эта хрень может быть изменена. При этом на половине компов она тупо при загрузке говорит "а нету принтера!" - и закрывается.
Извлечение SIM - далеко не единственное место, где может потребоваться такой инструмент. И именно для извлечения SIM инструмент подходит хреновенько - впрочем, вы в этом уже убедились.
Кнопка аппаратного сброса (RESET) в большинстве оборудования, допускающего такой сброс без вскрытия корпуса (различные коммутаторы-роутеры-контроллеры-камеры и т.п.), спрятана в корпусе за отверстием, и нажать на неё можно как раз такой битой. Там расстояние до кнопки поменьше будет, кстати. В общем, вы зря описали эту возможность так кратенько, что её и не сразу разглядишь..
Да, у меня в одном наборе есть такая бита, вспомнил... кстати, она подлиннее, миллиметров двадцать точно. Помнится, я её использовал для забивания в щели быстротвердеющего компаунда на основе эпоксидной смолы, и вполне успешно.
Ну так это и правильно. Оконные функции обрабатывают весь набор либо всё текущее окно. С какого перепугу она бы стала из-за какого-то CASE обрабатывать только часть выходного набора?
Не, ну а чё? Вот реально - товарищ сперва создаёт себе проблемы, а потом их мужественно преодолевает. Иначе я никак не могу интерпретировать его горячее желание сначала всё связать, получив очевидный JOIN multiplying, а потом посчитать количество уникальных значений.
У товарища Постгресс, да ещё и не факт что самый свежий. Так что CTE запросто могут кэшироваться на диске, что скажется на производительности отнюдь не лучшим образом.
А вот агрегирующие подзапросы и последующее связывание их с основной таблицей - это, скорее всего, решение. Конечно, условие отбора по INN должно быть как в подзапросах, так и в основном запросе. А если отбор идёт всегда строго по одному ИНН (т.е. выходных записей немного) - так и вообще самым разумным может быть использование агрегирующих коррелированных подзапросов в списке вывода.
Что же до понятности и отсутствия мешанины - так это всего лишь вопрос вменяемого форматирования и комментирования, по крайней мере в случае одиночного запроса.
Пожалуйста, дополните фотографию со схемой внешних связей таблиц собственно структурами таблиц (их CREATE TABLE). Вернее, наоборот, структуры (с внешними ключами) - это основа, а картинка - так, дополнение для наглядности. Ну и, конечно, лишние для содержания статьи поля можно опустить, или хотя бы закомментировать.
И когда пишете запрос, источником данных которого является более чем одна таблица - обязательно для абсолютно каждого поля исходной таблицы указывайте алиас этой таблицы. Иначе совершенно непонятно, что откуда берётся. Нет, у себя в коде можете творить всё, что угодно - но в статье подобное совершенно недопустимо.
На L2-свитчах (как и на L3 в режиме L2) Вы не построите сеть в виде циклического графа - там любые параллельные связи это автоматически петля со всеми вытекающими (идём в сторону STP, но опять же статья вообще не про эту область знаний).
Так называемые L2-коммутаторы не являются участниками ip-сетей и в алгоритме кратчайших путей не участвуют. Они являются мостами для организации взаимодействия подключенных маршрутизаторов, позволяя экономить физические порты роутеров и уменьшать количество настроек.
Это верно исключительно для тупых хабов НЕуправляемых коммутаторов. Но уже простейший управляемый коммутатор второго уровня очень даже способен повлиять на описываемый алгоритм. Например, включив где-нибудь изоляцию портов...
Специалистами компании используется термин «parallel optics» (параллельная оптика). Конечно, вернее будет сказать «оптические соединения, выполненные по параллельной схеме» или «параллельная передача данных», но мне кажется, что «параллельная оптика» верно отражает суть.
Вы знаете... когда говорят "parallel optics", то имеют в виду обычные "двуглазые" оптические модули (по одному волокну Rx, по другому Tx). А вот когда говорят о "параллельной передаче данных", то обычно имеют в виду агрегацию каналов.
Что-то я так и не понял, где и как будет разрешаться конфликт, описанный в примере параллельного изменения функции (те самые миграции с номерами 100, 101 и 102). Не, я, слава богу, не разработчик, и мне это всё не надо, просто любопытно... но я не понимаю, почему при создании вот этих миграций не фиксируется номер той миграции, которая послужила базой. Если бы было зафиксировано, что есть миграция 101 после миграции 100, есть миграция 102 после миграции 100, то такой конфликт никак не мог бы привести к тому, что применение второй миграции трёт изменения, внесённые первой миграцией, потому что миграция 102 не может выполняться после миграции 101, она идёт после миграции 100. И ловится такой конфликт буквально по щелчку пальцев. А разрешается - исключительно вручную. Ведь в примере с функцией требования никак не могут быть реализованы одновременно - либо то, либо другое, а если реализовать их вместе, получится третье, которого вообще никто не просил.
К сожалению, именно для не-разработчика трудно понимать ваш рассказ. Вы постоянно прыгаете с одного примера на другой (только что говорили про функцию, и сразу, вообще без перехода, начали про таблицу users), потом на третий... в результате всей цепочки и не видать.
Нет. Во-первых, это было любопытство, а не исследование (причём от обратного - сперва переохлаждённый раствор разнес стакан, прихватив с собой десяток других колб и стаканов, а уж потом стало любопытно, как оно выглядит в точке кипения). Во-вторых, дело было в начале 80-х, когда с оборудованием и вообще-то было сложновато, а уж померить температуру пара над поверхностью кипящей воды...
Ну почему? пробитая паркетная доска, благо размеры древесного рисунка вполне себе более-менее одинаковы что у них, что у нас, вполне позволяет прикинуть размеры объекта. И ваша оценка размеров вполне адекватна.
Если у него ставится WIA-драйвер, то можно попробовать в обход смарта, софтом третьих фирм.
Да щазз... Сам лично пробовал - ставлю чисто дрова. Ну так после первой же перезагрузки вылетает баннер "Получить приложение HP Smart". И затрахаешься его отключать.
Вроде Киосеры среднего класса более-менее соответствуют. Только не угробищное 1025-е... мне, например, так и не удалось заставить его сканировать через сеть.
Не, тонер, пусть даже и китайский, должен быть приличным. А не размятая землица из цветочного горшка.
HP Smart - голимое дерьмо. И глючное.
Даже если всё установлено - ему как два пальца потерять принтер при перезагрузке и больше его не найти.
А если не приведи господи у сетевого принтера изменился IP-адрес - вас ждёт увлекательнейший квест по поиску, где в программе эта хрень может быть изменена. При этом на половине компов она тупо при загрузке говорит "а нету принтера!" - и закрывается.
Не-не-не! Это ж дискриминация родителя, поставленного вторым, получается! Тут надо чего-нить типа first_parent и parent_first.
Непонятно, почему бы не воспользоваться тривиальным
power = 1 + len(str(total))А если не нравится, что для точных степеней десятки оно даст больше, чем нужно - ну можно отнять единичку.
А какие именно значения констант валят этот код? слишком большие?
Угу... но особенно обидно то, что вот серебряная куча дерьма - она-то как раз очень даже существует.
Извлечение SIM - далеко не единственное место, где может потребоваться такой инструмент. И именно для извлечения SIM инструмент подходит хреновенько - впрочем, вы в этом уже убедились.
Кнопка аппаратного сброса (RESET) в большинстве оборудования, допускающего такой сброс без вскрытия корпуса (различные коммутаторы-роутеры-контроллеры-камеры и т.п.), спрятана в корпусе за отверстием, и нажать на неё можно как раз такой битой. Там расстояние до кнопки поменьше будет, кстати. В общем, вы зря описали эту возможность так кратенько, что её и не сразу разглядишь..
Да, у меня в одном наборе есть такая бита, вспомнил... кстати, она подлиннее, миллиметров двадцать точно. Помнится, я её использовал для забивания в щели быстротвердеющего компаунда на основе эпоксидной смолы, и вполне успешно.
Ну так это и правильно. Оконные функции обрабатывают весь набор либо всё текущее окно. С какого перепугу она бы стала из-за какого-то CASE обрабатывать только часть выходного набора?
Не, ну а чё? Вот реально - товарищ сперва создаёт себе проблемы, а потом их мужественно преодолевает. Иначе я никак не могу интерпретировать его горячее желание сначала всё связать, получив очевидный JOIN multiplying, а потом посчитать количество уникальных значений.
У товарища Постгресс, да ещё и не факт что самый свежий. Так что CTE запросто могут кэшироваться на диске, что скажется на производительности отнюдь не лучшим образом.
А вот агрегирующие подзапросы и последующее связывание их с основной таблицей - это, скорее всего, решение. Конечно, условие отбора по INN должно быть как в подзапросах, так и в основном запросе. А если отбор идёт всегда строго по одному ИНН (т.е. выходных записей немного) - так и вообще самым разумным может быть использование агрегирующих коррелированных подзапросов в списке вывода.
Что же до понятности и отсутствия мешанины - так это всего лишь вопрос вменяемого форматирования и комментирования, по крайней мере в случае одиночного запроса.
Пожалуйста, дополните фотографию со схемой внешних связей таблиц собственно структурами таблиц (их CREATE TABLE). Вернее, наоборот, структуры (с внешними ключами) - это основа, а картинка - так, дополнение для наглядности. Ну и, конечно, лишние для содержания статьи поля можно опустить, или хотя бы закомментировать.
И когда пишете запрос, источником данных которого является более чем одна таблица - обязательно для абсолютно каждого поля исходной таблицы указывайте алиас этой таблицы. Иначе совершенно непонятно, что откуда берётся. Нет, у себя в коде можете творить всё, что угодно - но в статье подобное совершенно недопустимо.
Есть шикарный метод избавления от дубликатов - просто не плодить их.
LACP
Это верно исключительно для
тупых хабовНЕуправляемых коммутаторов. Но уже простейший управляемый коммутатор второго уровня очень даже способен повлиять на описываемый алгоритм. Например, включив где-нибудь изоляцию портов...Вы знаете... когда говорят "parallel optics", то имеют в виду обычные "двуглазые" оптические модули (по одному волокну Rx, по другому Tx). А вот когда говорят о "параллельной передаче данных", то обычно имеют в виду агрегацию каналов.
Так что стало ещё непонятнее..
Что-то я так и не понял, где и как будет разрешаться конфликт, описанный в примере параллельного изменения функции (те самые миграции с номерами 100, 101 и 102). Не, я, слава богу, не разработчик, и мне это всё не надо, просто любопытно... но я не понимаю, почему при создании вот этих миграций не фиксируется номер той миграции, которая послужила базой. Если бы было зафиксировано, что есть миграция 101 после миграции 100, есть миграция 102 после миграции 100, то такой конфликт никак не мог бы привести к тому, что применение второй миграции трёт изменения, внесённые первой миграцией, потому что миграция 102 не может выполняться после миграции 101, она идёт после миграции 100. И ловится такой конфликт буквально по щелчку пальцев. А разрешается - исключительно вручную. Ведь в примере с функцией требования никак не могут быть реализованы одновременно - либо то, либо другое, а если реализовать их вместе, получится третье, которого вообще никто не просил.
К сожалению, именно для не-разработчика трудно понимать ваш рассказ. Вы постоянно прыгаете с одного примера на другой (только что говорили про функцию, и сразу, вообще без перехода, начали про таблицу users), потом на третий... в результате всей цепочки и не видать.
Нет. Во-первых, это было любопытство, а не исследование (причём от обратного - сперва переохлаждённый раствор разнес стакан, прихватив с собой десяток других колб и стаканов, а уж потом стало любопытно, как оно выглядит в точке кипения). Во-вторых, дело было в начале 80-х, когда с оборудованием и вообще-то было сложновато, а уж померить температуру пара над поверхностью кипящей воды...