а так сразу в СБП будет привязано к ИНН и можно быстро мониторить, какие суммы приходят конкретному человеку
А сейчас что? СБП - он не сам по себе, у него всё равно и слева счёт, и справа счёт. И каждый счёт - в конкретном банке у конкретного владельца. А там есть сведения об ИНН.
Разве что раньше при анализе операций по СБП надо было тряхнуть соответствующий банк, а сейчас эту информацию банк сам на блюдечке.. но что-то мне подсказывает, что всю эту информацию банки и так куда-то отгружают на постоянной основе - может, в район центробанка, а может и сразу к федералам.
Вообще не понял, в чём "свежесть" идеи. Я, как раньше, перевожу или оплачиваю счёт по СБП, а с указанного срока банк ко всем передаваемым и сохраняемым реквизитам ещё добавит мой ИНН. И что? Для меня-то не изменится вообще ничего.
Более того - ИНН является обязательными сведениями, которые необходимо предоставить при открытии счёта. То есть у банков мой ИНН уже есть. И даже если в сохранённых сведениях о переводе/платеже ИНН не был записан, добавить его туда в процессе обработки - не самая сложная задача. То есть при поиске всякоразных дропперов и прочих мошенников уже сейчас, без всяких изменений, можно использовать группировку по ИНН плательщика.
Тогда зачем всё это? В голову приходят всякоразные варианты.
Ну, к примеру, банки ИНН-то собирают, но не проверяют их через базы ФНС. А теперь - будут обязаны проверять (ну или эта проверка получит чуть более иной статус). И за это заплатят определённые суммы.
Ну или под такое изменение вполне себе можно запросить (и, что главное, получить) определённое финансирование. Пусть там и делать-то считай ничего не нужно - но наши люди освоят любые суммы, и ещё не хватит.
А под аналитику и проверку можно будет создать новый отдел, с изрядным штатом (платежей-то вон сколько!). Тут тебе и бюджеты, и зарплаты, опять же родственника пристроить. Тоже небесполезная штука.
В общем, получается что-то вроде "Мы сделаем то, что уже есть, но объявим это самым новым новшеством.. а что ещё и поимеем с этого дела немножко профита, так оно само так получилось".
вместе с заданием шел скрипт наполнения таблицы тестовыми данными, который я тут приводить не буду. Он основан на функции random и всё время будет выдавать разный набор.
Совершенно напрасно. Пусть не воспроизведётся один к одному ваш набор записей. но тенденции останутся практически неизменными. Миллиона записей достаточно, чтобы их выровнять. Опять же всегда можно перегенерировать набор (несколько раз, или расширить его) и повторить - общее останется, а случайные выбросы уйдут. А сейчас - голые слова.
Но постойте, ведь в задании сказано, что
Сообщения обрабатываются в порядке возрастания значения поля “process_date“.
Здесь же получается, что 3-е число еще не обработано, 4-ое обработано, а 5-ое снова не обработано.
Странно все это подумал я и решил, что данный факт просто опишу в решении.
Что вы нашли странного? То, что сообщение взято на обработку, не означает, что оно будет обработано ранее более позднего. Как и не означает, что оно будет обработано вообще. Вполне себе нормальная ситуация, которую вы почему-то решили проигнорировать. так что ответ про "несостыковки по части логики" - совершенно справедливо.
использование бесполезного rows only и fetch вместо limit.
Документация PostgreSQL практически открытым текстом говорит, что LIMIT и FETCH - это разные синтаксические формы одной и той же операции. SQL:2008 ввёл, Postgres взял под козырёк - и не более. В чём вы видите различие в полезности?
А заодно объясните вот какую штуку... Кивая на необходимость сортировки по предложению ORDER BY, вы постоянно пишете так, словно PARTITION BY ну никакой сортировки не требует. Но ведь это неверно, для деления на партиции тоже необходима сортировка. Да, она может быть предрасчётной, если есть соответствующий индекс - но то же ведь относится и к ORDER BY. То есть в этом вопросе они равнозначны. А у вас в статье идёт чуть ли не противопоставление. Почему так?
стандартные подготовленные запросы в MySQL поддерживают исключительно скалярные параметры предопределённых типов, соответственно никакие списки не допускаются, ибо такого типа данных в MySQL просто нет. ,
В статье же рассказывается о вставке списка в текст. Через подготовленные запросы MySQL этого не сделать - хоть в текстовой форме, хоть через протокол, о котором вы говорите. То есть список вставляется в текст запроса до отправки на сервер БД - другого варианта осуществить такую вставку я не вижу. Нет, если говорить строго, то существует ненулевая вероятность, что в протоколе такая возможность есть, а из текстовой формы нет - но вы не представляете, как такое мне лично сомнительно..
А что самое неприятное - то, что автор статьи в очень неуверенной форме говорит: "Корректный ввод состоит только из чисел, запятых и пробелов; любые другие символы, скорее всего, вызовут ошибку". Я это понимаю однозначно - может и не вызвать. А дальше можно накрутить и до инъекции.
К слову, у MySQL есть такая штука как General Log. Если его включить, то мы увидим все поступившие на MySQl запросы, причём строго в той форме, в какой они поступили. Если бы автор статьи озаботился получением этих данных, вопросов, непониманий и разночтений бы возникало куда как меньше.
Вот автор пишет:
Этот код подготавливает запрос INSERT, привязывает строковые значения для названия и описания товара, а затем выполняет запрос. SQL, который в итоге выполнит Manticore, будет выглядеть так
Вот откуда он этот текст запроса взял? придумал? прикинул, как оно должно быть? вычитал из лога? Вот если бы в логе по показанному коду мы увидели показанный запрос, можно бы было смело утверждать, что prepared statement в Manticore есть эмуляция и фикция. А сейчас есть только вульгарное "а хрен знает"...
Manticore Search поддерживает prepared statements через стандартный протокол MySQL, и это даёт вам удобный инструмент для создания безопасных поисковых приложений.
"Prepared statements через стандартный протокол MySQL", на который вы ссылаетесь, предполагает, что на сервер MySQL передаются запросы:
PREPARE stmt FROM {строка с текстом запроса с плейсхолдерами,
или определённая пользователем переменная с текстом запроса};
EXECUTE stmt USING ( {набор параметров № 1} );
EXECUTE stmt USING ( {набор параметров № 2} );
...
DROP PREPARE stmt;
Однако всё, написанное далее, говорит о том, что Manticore Search ИГНОРИРУЕТ стандартные prepared statements в MySQL и выполняет все операции САМОСТОЯТЕЛЬНО. Экранирует переданные значения, конкатенирует их в текст запроса на место плейсхолдеров, и затем передаёт полученный текст запроса на MySQL. Самого обычного запроса. То есть это вовсе даже не серверный prepared statement, а его эмуляция на стороне клиента.
Но проблема в том, что Manticore Search - не MySQL. И он выполняет разнообразные экранирования по своему разумению, а не так, как это понимает MySQL. Нет, я понимаю, что разработчики не лохи, исследовали исходники MySQL вдоль и поперёк, сто раз всё проверили. Но все мы люди, все человеки, а потому потенция ошибки остаётся. И я, к примеру, не знаю, как будет обработана специально созданная текстовая строка в какой-нибудь экзотической или вообще несуществующей кодировке. Вы готовы гарантировать, что невозможно создание такой строки, которая после обработки кодом Manticore и конкатенации в текст запроса создаст-таки инъекцию? Я лично - нет.
PS. К слову, стандартные подготовленные запросы в MySQL поддерживают исключительно скалярные параметры предопределённых типов, соответственно никакие списки не допускаются, ибо такого типа данных в MySQL просто нет.
PPS. Стандартный prepared statement в MySQL прекрасно защитит от инъекции, даже если передаваемые в EXECUTE значения параметров будут злонамеренно модифицированы где-то в середине при прохождении трафика от клиента. Тогда как реализация на клиенте от такого не защищает.
Таким образом получается, что проводимость газов - это вовсе не из за продуктов сгорания (хотя, я думаю, они вносят свою роль тоже - та же сажа, то бишь, углерод) а из за ионизации.
Вы забываете про масштаб явления. Я не сказал, что без продуктов сгорания разряда не будет. Я сказал, что проводимость воздуха без этих компонентов при той же температуре (интегрально там порядка 900К) будет настолько мала, что никакого "стрелка начинает падать" вы не увидите. Она будет падать ну очень медленно.
Порог, когда термическая ионизация воздуха начинает быть заметной - это порядка 1500К. Столько может быть только в самой горячей части пламени свечи. Но вы в принципе не сможете заполнить весь объём между электродами газом такой температуры - наружные слои пламени заметно холоднее, да плюс гидродинамический захват наружных холодных масс воздуха, да охлаждение за счёт излучения, теплопередачи, да ламинарный пристеночный слой... так что практически весь эффект передачи заряда между электродами наблюдается именно благодаря продуктам частичного сгорания. Кстати, если использовать не свечу, а газовую горелку с метаном, эффект разряда будет заметно меньше.
И насчёт первого я был прав всё таки
Увы. Вы-то говорили о кристалле, а не абстрактно о составе. А вот в кристаллической решётке ионов нет. Есть практически только нейтральные атомы, у которых по сравнению с моноатомным состоянием несколько смещена электронная плотность. Точно так же абстрактно можно было написать и "представляющее собой соотношение атомов натрия и хлора 1:1" - и это тоже было бы правдой. Но точно так же не отражающей того, о чём мы говорим.
сделать соль жидкой вполне возможно, нужно всего лишь её бросить в воду
У вас была соль - индивидуальное вещество, может, даже чистое. А стал - раствор соли в воде. А вовсе даже не жидкая соль.
она состоит из натрия и хлора, представленных в составе кристаллической решётки в соотношении 1 к 1 (то есть количество ионов* натрия и ионов хлора одинаково), располагаются они в виде октаэдров, то есть, один ион хлора окружён шестью ионами натрия
В кристалле? ионы? Это что-то новенькое...
повышение температуры разбивает молекулы молекулярных газов, другими словами, ионизирует их
Нет, я понимаю, что лекция для колхозников - но всему же должны быть пределы. Если поверить тому, что вы пишете - то молекула хлора должна "разбиться" на два атома, один из которых имеет заряд -1, а второй +1, что весьма сомнительно при вменяемых температурах. Чтобы оторвать электрон у хлора, потребуется ну ОЧЕНЬ повышение температуры. Гораздо вероятнее, что образуется атомный газ, а не ионы.
то есть, ток начинает течь прямо через нагретый свечой воздух
Щазз! если между электродами гнать не продукты (частичного) сгорания, а сухой нагретый до той же температуры воздух - состаришься ждать, пока заряд через него утечёт.
Навскидку 30 или 31 марта, может ещё плюс-минус день. Сего года, есссно.
Просто я достаточно язвительно прошёлся по автору в комментариях, ну не первый раз у этого автора такие косяки, сколько можно.. потом более развёрнуто пообщались в диалогах на предмет фактических ошибок с подробным их разбором, по итогам чего статью сняли. Диалоги датированы 2 апреля.
Комментарии к снятой статье, кстати, тоже недоступны.
И сразу возникает вопрос - а пространство локов одно на оба типа наборов аргументов, или они различны? А то ведь случайно попасть грязным пальцем куда не надо - это у нас запросто..
Это исключает любые коллизии
Слишком категорично, а потому вызывает сомнения. Всё хорошо, пока инстанс Постгресса обслуживает экземпляры одного приложения, ну или пусть нескольких, но построенных с учётом совместного существования. А если на одном инстансе собрались приложения, которые о соседях и слыхом не слыхивали? Да и хэширование - оно, конечно, штука хорошая, но отсутствия коллизий на строго 100% не гарантирует.
Он блокирует только тех, кто проверяет тот же advisory lock.
Странно.. мне показалось, что тот, кто обнаружил, что уже существует чужой advisory lock с заданным номером, сам себя блокирует. Вернее, ограничивает.
То есть с VPN я опасен только для товарищей из власти... которые, к слову, тоже где-то как-то соседи.
Кстати, с топором я для соседей опасен только если вдруг сделаю какой неправильный вывод.. да и то не всегда и не сразу. Впрочем, до вербовки дело уж точно не дойдёт.
Ну так это не проблема того, что в школе стало больше учеников. Проблема в том, что НЕ стало в этой школе больше учителей. Отсюда и избыточное количество обучаемых в классе, и недостаток внимания отдельному ученику. Косвенно, возможно, это и проблема площадей - сама-то школа от того, что в ней теперь учится на 60% больше учеников, не раздвинулась, а если в школе 20 помещений, то 30 классов одновременно заниматься ну никак не смогут. А вторая смена - не решение.
При нормальных соотношениях полтыщи учеников на школу - совсем не проблема. У нас в школе учеников куда как больше было, ничего, выучились, локтями не толкаясь, классы были в среднем по 20 учеников.
О минусах такой реализации, думаю, и говорить не стоит.
Собственно SQL-щикам известно, что принципиально существует две стратегии выполнения CTE. Это кэширование и инлайнинг.
С кэшированием (и его предельной версией - материализацией) всё понятно - это правильный и логичный подход. А заодно гарантирующий детерминированный результат. Правда, детерминированный не в смысле результата выполнения запроса, а в том смысле, что эта стратегия гарантирует идентичность наборов записей, используемых копиями CTE. Даже если само CTE содержит недетерминированные конструкции.
А вот инлайнинг - это весьма спорная стратегия. Особенно если внутри есть нечто недетерминированное. Каждая заинлайненная копия вернёт уникальный набор записей, не совпадающий с таковым, возвращённым другой копией. И неудивительно, что в конечном итоге результат может сильно отличаться не то что от ожидаемого, но и просто от вменяемого. Что вы как раз и наблюдаете.
Но при этом и инлайнинг имеет право на существование - просто потому, что кратное выполнение CTE может оказаться выгоднее по ресурсам, чем кэширование. Но для корректного использования инлайнинга СУБД должна грамотно исследовать код CTE и убедиться, что он производит гарантированно детерминированный результат, и что при этом план с кратным исполнением более выгоден, чем план с кэшированием. Некоторые СУБД это всё же умеют. Вроде бы...
Если ClickHouse использует инлайнинг и описывает это в документации, то он (или она? или вообще оно?) просто сваливает такой анализ на программиста. Не прочитал, не проанализировал, не учёл - ну хлебай полной ложкой. А если не описывает - то это несомненный косяк. Который, как вы говорите, уже обнаружили и даже начали исправлять.
С другой стороны, и программист тоже имеет право поучаствовать... наверное. Хоть язык изначально и декларативный. А потому возможность указать, какую стратегию использовать - ну если и не "должна быть", то во всяком случае невредно. И все шишки за свой счёт.
PS. К слову, было вовсе необязательно генерить миллион значений и обнаруживать косяк по косвенным признакам. Простой запрос должен по идее сразу и явно продемонстрировать эту проблему просто на выводимом результате выполнения:
WITH cte_numbers AS (
SELECT num FROM generateRandom(‘num UInt64’, NULL) LIMIT 2
)
SELECT t1.num, t2.num
FROM cte_numbers t1, cte_numbers t2;
По поводу похожей статьи, жду ссылку. Пока звучит как легенда.
Ничем не могу помочь - статья снята с публикации, и соответственно недоступна, в том числе на посмотреть или просто дать ссылку. А, судя по количеству и особенно качеству ошибок, ожидать её ре-публикации бессмысленно..
легаси без индексов годами, это не баг, а рынок. Кто не встречал, тому повезло. ORM и Django проекты живут по своим законам, это немного другой мир
Но у вас-то все они живут в одной системе. Нет, если вы скажете, что в Django возможно такое, что связи в модели есть, а внешних ключей да индексов, соответствующих этим связям, нет и никогда не было - поверю как имеющему дело с этой ORM, ибо сам не владею в принципе, а изучать по такому поводу уж точно лень. Просто поставлю в уме ещё один жирнючий минус.
сегодня в России (барабанная дробь) - 38,5К школ. Для сравнения: в 2000 году их было почти 69К. Получается, за 25 лет число школ сократилось примерно в полтора раза. При этом число школьников за тот же период снизилось гораздо слабее - с 20 до 18 миллионов, то есть примерно на 10%.
А поскольку все эти школьники таки учатся в школах, то просто в среднем количество учеников в одной школе увеличилось где-то на 60%, с 290 до 470 учащихся. И всё. И не вижу особого повода волосики на себе рвать.
А вот то, что сократилось абсолютное количество учащихся - это и вправду та проблема, которая должна всерьёз волновать. Да только не очень-то и волнует, походу - чем меньше учащихся, тем дешевле их обучение и тем больше экономия по сравнению с предыдущим периодом. А уж кому девать, всегда найдётся.
PS. Правда, заглянул я сюда, увидев 6/1*12, да и то лишь за тем, чтобы напомнить, что "чтобы корова меньше ела и давала больше молока, её надо меньше кормить и больше доить".
С точки зрения SQL-щика там легаси не при чём, просто там болван доделывал за идиотом. Вот как вся эта архитектура БД могла жить годами - ГОДАМИ! - без индексов? КАК? Там должно было тормозить всё, везде и всегда, и никакой Постгресс это не вывезет.
При этом непонятен вот какой момент. Поверх СУБД работает ORM. Чтобы она правильно понимала, с чем работает, в модели должны быть описаны связи, а на стороне СУБД это должно быть поддержано соответствующими внешними ключами и необходимыми для их обслуживания индексами. Но индексов-то НЕТ! Как же оно так существовало-то?
К слову, и проблема N+1 тоже не сама появилась - она создана добрыми руками очередного программиста, написавшего вот тот кривой код, который вы нам показываете.
В общем, всё описанное как-то слабо похоже на правду, скорее это придуманный, но не продуманный синтетический пример.
PS. К тому же уж больно сильно смахивает на недавно опубликованную, раскритикованную за кучу ошибок и в результате безвозвратно снятую с публикации статью за авторством одной дамы - почти что с точностью до текстов запросов.
А сейчас что? СБП - он не сам по себе, у него всё равно и слева счёт, и справа счёт. И каждый счёт - в конкретном банке у конкретного владельца. А там есть сведения об ИНН.
Разве что раньше при анализе операций по СБП надо было тряхнуть соответствующий банк, а сейчас эту информацию банк сам на блюдечке.. но что-то мне подсказывает, что всю эту информацию банки и так куда-то отгружают на постоянной основе - может, в район центробанка, а может и сразу к федералам.
То есть мониторить можно - уже сейчас.
Вообще не понял, в чём "свежесть" идеи. Я, как раньше, перевожу или оплачиваю счёт по СБП, а с указанного срока банк ко всем передаваемым и сохраняемым реквизитам ещё добавит мой ИНН. И что? Для меня-то не изменится вообще ничего.
Более того - ИНН является обязательными сведениями, которые необходимо предоставить при открытии счёта. То есть у банков мой ИНН уже есть. И даже если в сохранённых сведениях о переводе/платеже ИНН не был записан, добавить его туда в процессе обработки - не самая сложная задача. То есть при поиске всякоразных дропперов и прочих мошенников уже сейчас, без всяких изменений, можно использовать группировку по ИНН плательщика.
Тогда зачем всё это? В голову приходят всякоразные варианты.
Ну, к примеру, банки ИНН-то собирают, но не проверяют их через базы ФНС. А теперь - будут обязаны проверять (ну или эта проверка получит чуть более иной статус). И за это заплатят определённые суммы.
Ну или под такое изменение вполне себе можно запросить (и, что главное, получить) определённое финансирование. Пусть там и делать-то считай ничего не нужно - но наши люди освоят любые суммы, и ещё не хватит.
А под аналитику и проверку можно будет создать новый отдел, с изрядным штатом (платежей-то вон сколько!). Тут тебе и бюджеты, и зарплаты, опять же родственника пристроить. Тоже небесполезная штука.
В общем, получается что-то вроде "Мы сделаем то, что уже есть, но объявим это самым новым новшеством.. а что ещё и поимеем с этого дела немножко профита, так оно само так получилось".
Совершенно напрасно. Пусть не воспроизведётся один к одному ваш набор записей. но тенденции останутся практически неизменными. Миллиона записей достаточно, чтобы их выровнять. Опять же всегда можно перегенерировать набор (несколько раз, или расширить его) и повторить - общее останется, а случайные выбросы уйдут. А сейчас - голые слова.
Что вы нашли странного? То, что сообщение взято на обработку, не означает, что оно будет обработано ранее более позднего. Как и не означает, что оно будет обработано вообще. Вполне себе нормальная ситуация, которую вы почему-то решили проигнорировать. так что ответ про "несостыковки по части логики" - совершенно справедливо.
Документация PostgreSQL практически открытым текстом говорит, что LIMIT и FETCH - это разные синтаксические формы одной и той же операции. SQL:2008 ввёл, Postgres взял под козырёк - и не более. В чём вы видите различие в полезности?
А заодно объясните вот какую штуку... Кивая на необходимость сортировки по предложению ORDER BY, вы постоянно пишете так, словно PARTITION BY ну никакой сортировки не требует. Но ведь это неверно, для деления на партиции тоже необходима сортировка. Да, она может быть предрасчётной, если есть соответствующий индекс - но то же ведь относится и к ORDER BY. То есть в этом вопросе они равнозначны. А у вас в статье идёт чуть ли не противопоставление. Почему так?
Повторю ещё раз:
В статье же рассказывается о вставке списка в текст. Через подготовленные запросы MySQL этого не сделать - хоть в текстовой форме, хоть через протокол, о котором вы говорите. То есть список вставляется в текст запроса до отправки на сервер БД - другого варианта осуществить такую вставку я не вижу. Нет, если говорить строго, то существует ненулевая вероятность, что в протоколе такая возможность есть, а из текстовой формы нет - но вы не представляете, как такое мне лично сомнительно..
А что самое неприятное - то, что автор статьи в очень неуверенной форме говорит: "Корректный ввод состоит только из чисел, запятых и пробелов; любые другие символы, скорее всего, вызовут ошибку". Я это понимаю однозначно - может и не вызвать. А дальше можно накрутить и до инъекции.
К слову, у MySQL есть такая штука как General Log. Если его включить, то мы увидим все поступившие на MySQl запросы, причём строго в той форме, в какой они поступили. Если бы автор статьи озаботился получением этих данных, вопросов, непониманий и разночтений бы возникало куда как меньше.
Вот автор пишет:
Вот откуда он этот текст запроса взял? придумал? прикинул, как оно должно быть? вычитал из лога? Вот если бы в логе по показанному коду мы увидели показанный запрос, можно бы было смело утверждать, что prepared statement в Manticore есть эмуляция и фикция. А сейчас есть только вульгарное "а хрен знает"...
"Prepared statements через стандартный протокол MySQL", на который вы ссылаетесь, предполагает, что на сервер MySQL передаются запросы:
Однако всё, написанное далее, говорит о том, что Manticore Search ИГНОРИРУЕТ стандартные prepared statements в MySQL и выполняет все операции САМОСТОЯТЕЛЬНО. Экранирует переданные значения, конкатенирует их в текст запроса на место плейсхолдеров, и затем передаёт полученный текст запроса на MySQL. Самого обычного запроса. То есть это вовсе даже не серверный prepared statement, а его эмуляция на стороне клиента.
Но проблема в том, что Manticore Search - не MySQL. И он выполняет разнообразные экранирования по своему разумению, а не так, как это понимает MySQL. Нет, я понимаю, что разработчики не лохи, исследовали исходники MySQL вдоль и поперёк, сто раз всё проверили. Но все мы люди, все человеки, а потому потенция ошибки остаётся. И я, к примеру, не знаю, как будет обработана специально созданная текстовая строка в какой-нибудь экзотической или вообще несуществующей кодировке. Вы готовы гарантировать, что невозможно создание такой строки, которая после обработки кодом Manticore и конкатенации в текст запроса создаст-таки инъекцию? Я лично - нет.
PS. К слову, стандартные подготовленные запросы в MySQL поддерживают исключительно скалярные параметры предопределённых типов, соответственно никакие списки не допускаются, ибо такого типа данных в MySQL просто нет.
PPS. Стандартный prepared statement в MySQL прекрасно защитит от инъекции, даже если передаваемые в EXECUTE значения параметров будут злонамеренно модифицированы где-то в середине при прохождении трафика от клиента. Тогда как реализация на клиенте от такого не защищает.
Вы забываете про масштаб явления. Я не сказал, что без продуктов сгорания разряда не будет. Я сказал, что проводимость воздуха без этих компонентов при той же температуре (интегрально там порядка 900К) будет настолько мала, что никакого "стрелка начинает падать" вы не увидите. Она будет падать ну очень медленно.
Порог, когда термическая ионизация воздуха начинает быть заметной - это порядка 1500К. Столько может быть только в самой горячей части пламени свечи. Но вы в принципе не сможете заполнить весь объём между электродами газом такой температуры - наружные слои пламени заметно холоднее, да плюс гидродинамический захват наружных холодных масс воздуха, да охлаждение за счёт излучения, теплопередачи, да ламинарный пристеночный слой... так что практически весь эффект передачи заряда между электродами наблюдается именно благодаря продуктам частичного сгорания. Кстати, если использовать не свечу, а газовую горелку с метаном, эффект разряда будет заметно меньше.
Увы. Вы-то говорили о кристалле, а не абстрактно о составе. А вот в кристаллической решётке ионов нет. Есть практически только нейтральные атомы, у которых по сравнению с моноатомным состоянием несколько смещена электронная плотность. Точно так же абстрактно можно было написать и "представляющее собой соотношение атомов натрия и хлора 1:1" - и это тоже было бы правдой. Но точно так же не отражающей того, о чём мы говорим.
У вас была соль - индивидуальное вещество, может, даже чистое. А стал - раствор соли в воде. А вовсе даже не жидкая соль.
В кристалле? ионы? Это что-то новенькое...
Нет, я понимаю, что лекция для колхозников - но всему же должны быть пределы. Если поверить тому, что вы пишете - то молекула хлора должна "разбиться" на два атома, один из которых имеет заряд -1, а второй +1, что весьма сомнительно при вменяемых температурах. Чтобы оторвать электрон у хлора, потребуется ну ОЧЕНЬ повышение температуры. Гораздо вероятнее, что образуется атомный газ, а не ионы.
Щазз! если между электродами гнать не продукты (частичного) сгорания, а сухой нагретый до той же температуры воздух - состаришься ждать, пока заряд через него утечёт.
Дальше не буду читать - надоело.
Навскидку 30 или 31 марта, может ещё плюс-минус день. Сего года, есссно.
Просто я достаточно язвительно прошёлся по автору в комментариях, ну не первый раз у этого автора такие косяки, сколько можно.. потом более развёрнуто пообщались в диалогах на предмет фактических ошибок с подробным их разбором, по итогам чего статью сняли. Диалоги датированы 2 апреля.
Комментарии к снятой статье, кстати, тоже недоступны.
И сразу возникает вопрос - а пространство локов одно на оба типа наборов аргументов, или они различны? А то ведь случайно попасть грязным пальцем куда не надо - это у нас запросто..
Слишком категорично, а потому вызывает сомнения. Всё хорошо, пока инстанс Постгресса обслуживает экземпляры одного приложения, ну или пусть нескольких, но построенных с учётом совместного существования. А если на одном инстансе собрались приложения, которые о соседях и слыхом не слыхивали? Да и хэширование - оно, конечно, штука хорошая, но отсутствия коллизий на строго 100% не гарантирует.
Странно.. мне показалось, что тот, кто обнаружил, что уже существует чужой advisory lock с заданным номером, сам себя блокирует. Вернее, ограничивает.
То есть с VPN я опасен только для товарищей из власти... которые, к слову, тоже где-то как-то соседи.
Кстати, с топором я для соседей опасен только если вдруг сделаю какой неправильный вывод.. да и то не всегда и не сразу. Впрочем, до вербовки дело уж точно не дойдёт.
Ну так это не проблема того, что в школе стало больше учеников. Проблема в том, что НЕ стало в этой школе больше учителей. Отсюда и избыточное количество обучаемых в классе, и недостаток внимания отдельному ученику. Косвенно, возможно, это и проблема площадей - сама-то школа от того, что в ней теперь учится на 60% больше учеников, не раздвинулась, а если в школе 20 помещений, то 30 классов одновременно заниматься ну никак не смогут. А вторая смена - не решение.
При нормальных соотношениях полтыщи учеников на школу - совсем не проблема. У нас в школе учеников куда как больше было, ничего, выучились, локтями не толкаясь, классы были в среднем по 20 учеников.
Собственно SQL-щикам известно, что принципиально существует две стратегии выполнения CTE. Это кэширование и инлайнинг.
С кэшированием (и его предельной версией - материализацией) всё понятно - это правильный и логичный подход. А заодно гарантирующий детерминированный результат. Правда, детерминированный не в смысле результата выполнения запроса, а в том смысле, что эта стратегия гарантирует идентичность наборов записей, используемых копиями CTE. Даже если само CTE содержит недетерминированные конструкции.
А вот инлайнинг - это весьма спорная стратегия. Особенно если внутри есть нечто недетерминированное. Каждая заинлайненная копия вернёт уникальный набор записей, не совпадающий с таковым, возвращённым другой копией. И неудивительно, что в конечном итоге результат может сильно отличаться не то что от ожидаемого, но и просто от вменяемого. Что вы как раз и наблюдаете.
Но при этом и инлайнинг имеет право на существование - просто потому, что кратное выполнение CTE может оказаться выгоднее по ресурсам, чем кэширование. Но для корректного использования инлайнинга СУБД должна грамотно исследовать код CTE и убедиться, что он производит гарантированно детерминированный результат, и что при этом план с кратным исполнением более выгоден, чем план с кэшированием. Некоторые СУБД это всё же умеют. Вроде бы...
Если ClickHouse использует инлайнинг и описывает это в документации, то он (или она? или вообще оно?) просто сваливает такой анализ на программиста. Не прочитал, не проанализировал, не учёл - ну хлебай полной ложкой. А если не описывает - то это несомненный косяк. Который, как вы говорите, уже обнаружили и даже начали исправлять.
С другой стороны, и программист тоже имеет право поучаствовать... наверное. Хоть язык изначально и декларативный. А потому возможность указать, какую стратегию использовать - ну если и не "должна быть", то во всяком случае невредно. И все шишки за свой счёт.
PS. К слову, было вовсе необязательно генерить миллион значений и обнаруживать косяк по косвенным признакам. Простой запрос должен по идее сразу и явно продемонстрировать эту проблему просто на выводимом результате выполнения:
С нетерпением жду методичку по выявлению кухонных ножей на кухнях. Страшный же предмет! Сколько ими было порезано народу - жуть!
И топоры на дачах не забыть. Тоже весьма опасная штука.
Спасибо за обстоятельный ответ. Очень познавательно... сочувствую.
Да я по таким поводам не минусую статьи. Ни как правило, ни в данном случае.
Ничем не могу помочь - статья снята с публикации, и соответственно недоступна, в том числе на посмотреть или просто дать ссылку. А, судя по количеству и особенно качеству ошибок, ожидать её ре-публикации бессмысленно..
Но у вас-то все они живут в одной системе. Нет, если вы скажете, что в Django возможно такое, что связи в модели есть, а внешних ключей да индексов, соответствующих этим связям, нет и никогда не было - поверю как имеющему дело с этой ORM, ибо сам не владею в принципе, а изучать по такому поводу уж точно лень. Просто поставлю в уме ещё один жирнючий минус.
А поскольку все эти школьники таки учатся в школах, то просто в среднем количество учеников в одной школе увеличилось где-то на 60%, с 290 до 470 учащихся. И всё. И не вижу особого повода волосики на себе рвать.
А вот то, что сократилось абсолютное количество учащихся - это и вправду та проблема, которая должна всерьёз волновать. Да только не очень-то и волнует, походу - чем меньше учащихся, тем дешевле их обучение и тем больше экономия по сравнению с предыдущим периодом. А уж кому девать, всегда найдётся.
PS. Правда, заглянул я сюда, увидев 6/1*12, да и то лишь за тем, чтобы напомнить, что "чтобы корова меньше ела и давала больше молока, её надо меньше кормить и больше доить".
С точки зрения SQL-щика там легаси не при чём, просто там болван доделывал за идиотом. Вот как вся эта архитектура БД могла жить годами - ГОДАМИ! - без индексов? КАК? Там должно было тормозить всё, везде и всегда, и никакой Постгресс это не вывезет.
При этом непонятен вот какой момент. Поверх СУБД работает ORM. Чтобы она правильно понимала, с чем работает, в модели должны быть описаны связи, а на стороне СУБД это должно быть поддержано соответствующими внешними ключами и необходимыми для их обслуживания индексами. Но индексов-то НЕТ! Как же оно так существовало-то?
К слову, и проблема N+1 тоже не сама появилась - она создана добрыми руками очередного программиста, написавшего вот тот кривой код, который вы нам показываете.
В общем, всё описанное как-то слабо похоже на правду, скорее это придуманный, но не продуманный синтетический пример.
PS. К тому же уж больно сильно смахивает на недавно опубликованную, раскритикованную за кучу ошибок и в результате безвозвратно снятую с публикации статью за авторством одной дамы - почти что с точностью до текстов запросов.
Так ведь добрым словом и пистолетом - оно надёжнее..
Конечно, проще сразу взять два пистолета - но уж больно палевно..