Я не о том немного. Если человечество внезапно оказывается уничтоженным, например, гигантским метеоритом, после которого большая часть жизни перестала существовать, то последующие цивилизации через тысячи/миллионы лет могут найти месторождения того же золота с необычно высокой концентрацией на месте нынешних золотохранилищ, некоторых музеев и т.п. Возможно, даже не слишком глубоко от поверхности. На месте нынешних городов вообще будет вся таблица Менделеева в концентрациях сильно выше природных, потому что металлы копились десятилетиями/веками на компактных территориях, при том что транспортировались с обширных территорий. Безусловно, освоить технологии их извлечения будет непросто, но нынешнее человечество с этим справилось, так что нельзя исключать, что и будущее человечество справится. Была бы энергия.
Update. А, ну и да, каждый трансформатор и электродвигатель - это медный самородок весьма внушительного размера. Чтобы обрабатывать самородную медь, высокоразвитой технологии не потребуется. Так что конкретно по меди нынешнее человечество оставит серьёзный подарок будущему, многократно повысив концентрацию легкодоступной меди, по сравнению с тем, что было доступно в древности.
Как раз-таки с металлами всё будет относительно неплохо - на месте современных промышленных конструкций будут обнаруживать многотонные "самородки" или "руды" с концентрацией сильно выше природных. Вот с нефтью-газом будут сложности, да.
Можно, но зачем? Тем более, если доля просроченных записей невелика, а выборка большая, сделав более селектиный джойн мы еще и запрос сделаем более эффективным, тогда как в случае CASE данные из связанной таблицы будут запрошены, даже если они нам не понадобятся.
OK, мы хотим вывести все договоры (таблица A), и для тех из них, у которых статус "Просрочен очередной платеж" хотим вывести дату последнего платежа, которую получаем из приджойненой таблицы B. Как выразить это через WHERE?
Еще ошибка, с которой встречался больше одного раза. Допустим, мы связываем три таблицы A, B, C такие, что мы знаем, что для каждой записи в B есть запись в C, и их можно связывать через INNER JOIN: B JOIN C ON...
При этом не для каждой записи в A есть соответствие в B, и тут нужен LEFT JOIN.
В результате получается что-то вроде
FROM A LEFT JOIN B ON... JOIN C ON...
И в результате записи из A отсекаются, как если бы мы применили A JOIN B.
На модельном примере с тремя таблицами очевидно, а в большом запросе может быть непросто заметить, что замены одного INNER на LEFT может быть недостаточно, и надо "каскадно" заменить остальные INNER-ы, которые могут повлиять на результирующий набор строк.
Если мы джойним к таблице B, но не хотим рассматривать записи с признаком IS_DELETED (ну или STATUS='Deleted'), расскажите, пожалуйста, как это сделать через WHERE. Я напомню, что речь про LEFT JOIN, т.е. записи в таблице A мы отсекать не планируем.
(Да, это решаемо, например, с использованием WITH или VIEW, например, но все-таки куда проще через ON IS_DELETED=FALSE).
Ну, OUTER в принципе избыточно, т.к. LEFT подразумевает OUTER. Но ваш вопрос вполне актуален для случаев, когда нам надо написать LEFT MERGE JOIN или INNER HASH JOIN, например.
Лично мне вариант с коридорами неудобен тем, что от замены одного оператора может поползти верстка большого куска запроса (в пределе - запроса целиком). Заменил один LEFT на INNER - и либо нарушил аккуратное форматирование ("ад перфекциониста"), либо получил diff на 200 строк.
Не оспаривая написанного вами, всё же отмечу, что человек, способный стройно сформулировать мысль в режиме реального времени, без тщательного рефакторинга, - и в написании кода может оказаться более продуктивным, т.к. он будет получаться логичным с первого раза, без многократных переделок.
Как вариант - делать выгрузки такого же размера примерно каждый день, чтобы а) создать впечатление, что это нормальный рабочий процесс, а не разовая аномалия, б) затереть следы утекшей выгрузки, в) убедиться, что не привлёк внимания СБ. А базу продавать через год, когда следов уже не найти. В идеале - после списания АРМ2 с регламентным уничтожением HDD, но это можно и не дождаться.
И ещё, чтобы тепловая карта показывала объективный результат, величина ячеек должна быть одинаковой на всей площади. Иначе даже абсолютно равномерное распределение точек будет визуализировано как имеющее бОльшую плотность в той части, где ячейки крупнее. Поэтому проекцию стоит выбирать равновеликую.
Как зарядка для ума - неплохое упражнение. С практической точки зрения - вариант не очень универсальный.
Думаю, проблемы с подсчётом расстояний между между точками с использованием geography были вызваны тем, что вы считали расстояния от каждой точки до каждой, что, очевидно, слишком ресурсозатратно. Правильнее было бы спроецировать географические координаты в целевую СК (в ту, в которой будет происходить отображение), а в ней уже кластеризовать по квадратной сетке нужного размера. В вашем же случае сделать сетку квадратной, а не прямоугольной или трапецевидной - задача нетривиальная.
Но мне непонятно, что мешает извлечь коммит 5-летней давности, провести проверку, зафиксировать ошибки, извлечь последний коммит и провести повторную проверку.
Статья называется "Представляем Q# Formatter", а по факту её содержимое больше напоминает release notes очередной версии продукта, который уже хорошо знаком читателям.
И то, если кто-то глобально на заменил табы на пробелы (или наоборот) где-то ближе к концу проекта
Это довод уровня "у меня нет проф. деформации, а значит её не бывает".
Я не о том немного. Если человечество внезапно оказывается уничтоженным, например, гигантским метеоритом, после которого большая часть жизни перестала существовать, то последующие цивилизации через тысячи/миллионы лет могут найти месторождения того же золота с необычно высокой концентрацией на месте нынешних золотохранилищ, некоторых музеев и т.п. Возможно, даже не слишком глубоко от поверхности. На месте нынешних городов вообще будет вся таблица Менделеева в концентрациях сильно выше природных, потому что металлы копились десятилетиями/веками на компактных территориях, при том что транспортировались с обширных территорий. Безусловно, освоить технологии их извлечения будет непросто, но нынешнее человечество с этим справилось, так что нельзя исключать, что и будущее человечество справится. Была бы энергия.
Update. А, ну и да, каждый трансформатор и электродвигатель - это медный самородок весьма внушительного размера. Чтобы обрабатывать самородную медь, высокоразвитой технологии не потребуется. Так что конкретно по меди нынешнее человечество оставит серьёзный подарок будущему, многократно повысив концентрацию легкодоступной меди, по сравнению с тем, что было доступно в древности.
Как раз-таки с металлами всё будет относительно неплохо - на месте современных промышленных конструкций будут обнаруживать многотонные "самородки" или "руды" с концентрацией сильно выше природных. Вот с нефтью-газом будут сложности, да.
Значит, все-таки создали! :-)
Можно, но зачем? Тем более, если доля просроченных записей невелика, а выборка большая, сделав более селектиный джойн мы еще и запрос сделаем более эффективным, тогда как в случае CASE данные из связанной таблицы будут запрошены, даже если они нам не понадобятся.
OK, мы хотим вывести все договоры (таблица A), и для тех из них, у которых статус "Просрочен очередной платеж" хотим вывести дату последнего платежа, которую получаем из приджойненой таблицы B. Как выразить это через WHERE?
В таблице B
Еще ошибка, с которой встречался больше одного раза. Допустим, мы связываем три таблицы A, B, C такие, что мы знаем, что для каждой записи в B есть запись в C, и их можно связывать через INNER JOIN: B JOIN C ON...
При этом не для каждой записи в A есть соответствие в B, и тут нужен LEFT JOIN.
В результате получается что-то вроде
FROM A LEFT JOIN B ON... JOIN C ON...
И в результате записи из A отсекаются, как если бы мы применили A JOIN B.
На модельном примере с тремя таблицами очевидно, а в большом запросе может быть непросто заметить, что замены одного INNER на LEFT может быть недостаточно, и надо "каскадно" заменить остальные INNER-ы, которые могут повлиять на результирующий набор строк.
Если мы джойним к таблице B, но не хотим рассматривать записи с признаком IS_DELETED (ну или STATUS='Deleted'), расскажите, пожалуйста, как это сделать через WHERE. Я напомню, что речь про LEFT JOIN, т.е. записи в таблице A мы отсекать не планируем.
(Да, это решаемо, например, с использованием WITH или VIEW, например, но все-таки куда проще через ON IS_DELETED=FALSE).
My wife says: if you keep being so pedantic you'll have less and less friends!
I say: no way! Because I'll be having fewer and fewer of them.
Вот тут я что-то сомневаюсь. It это subject, me - object. Вот и получается it's me. Аналогично - it's him, it's her и т.п., а не it's he, it's she.
Ну, OUTER в принципе избыточно, т.к. LEFT подразумевает OUTER. Но ваш вопрос вполне актуален для случаев, когда нам надо написать LEFT MERGE JOIN или INNER HASH JOIN, например.
Лично мне вариант с коридорами неудобен тем, что от замены одного оператора может поползти верстка большого куска запроса (в пределе - запроса целиком). Заменил один LEFT на INNER - и либо нарушил аккуратное форматирование ("ад перфекциониста"), либо получил diff на 200 строк.
Не оспаривая написанного вами, всё же отмечу, что человек, способный стройно сформулировать мысль в режиме реального времени, без тщательного рефакторинга, - и в написании кода может оказаться более продуктивным, т.к. он будет получаться логичным с первого раза, без многократных переделок.
Как вариант - делать выгрузки такого же размера примерно каждый день, чтобы а) создать впечатление, что это нормальный рабочий процесс, а не разовая аномалия, б) затереть следы утекшей выгрузки, в) убедиться, что не привлёк внимания СБ. А базу продавать через год, когда следов уже не найти. В идеале - после списания АРМ2 с регламентным уничтожением HDD, но это можно и не дождаться.
И ещё, чтобы тепловая карта показывала объективный результат, величина ячеек должна быть одинаковой на всей площади. Иначе даже абсолютно равномерное распределение точек будет визуализировано как имеющее бОльшую плотность в той части, где ячейки крупнее. Поэтому проекцию стоит выбирать равновеликую.
Как зарядка для ума - неплохое упражнение. С практической точки зрения - вариант не очень универсальный.
Думаю, проблемы с подсчётом расстояний между между точками с использованием geography были вызваны тем, что вы считали расстояния от каждой точки до каждой, что, очевидно, слишком ресурсозатратно. Правильнее было бы спроецировать географические координаты в целевую СК (в ту, в которой будет происходить отображение), а в ней уже кластеризовать по квадратной сетке нужного размера. В вашем же случае сделать сетку квадратной, а не прямоугольной или трапецевидной - задача нетривиальная.
Не может, т.к. в английском idiot ударение на первый слог, а настолько недослышать - это надо очень постараться.
Мне стоило бы обновить комменты перед отправкой...
Но мне непонятно, что мешает извлечь коммит 5-летней давности, провести проверку, зафиксировать ошибки, извлечь последний коммит и провести повторную проверку.
Статья называется "Представляем Q# Formatter", а по факту её содержимое больше напоминает release notes очередной версии продукта, который уже хорошо знаком читателям.