Вот конкретно проблему поиска и замены в сотнях файлов XLSX как раз можно было решить за секунды плюс несколько минут на написание PowerShell скрипта, если воспользоваться тем фактом, что XLSX - это zip-архив с XML-ками. Макросы я бы оставил для каких-нибудь более сложных манипуляций.
По-моему, тема сообщений об ошибках неполна без рассказа об их локализации. В теории, там всё легко, локаль настраивается в одном месте, но в деталях вылезают всякие неприятные мелочи, вроде того, что текст сообщения выводится по-русски, а даты в плейсхолдерах форматируется в US-формате.
Всех подробностей не помню, но где-то что-то приходилось подпиливать напильником. И это у нас ещё не было потребности отдавать разным пользователям ответ на разном языке, там бы наверняка ещё что-то вылезло.
Если вы используете стороннюю библиотеку, в которой такие структуры не определены, а вам хочется свой код сделать более лаконичным и наглядным - то использование алиасов позволит это сделать без введения доп. типов, конвертации, нагрузки на GC и т.п. Понятно, что этот вариант использования является довольно узким, и без него вполне можно же жить, ну так это вообще ко всем алиасам относится (тот же `using static ...` всего лишь позволяет чуточку меньше символов писать. Мелкая, иногда приятная, но точно не необходимая "плюшка")
Джуниоры и Миддлы могут предложить новое решение с их прежнего места работы/учёбы,
Тут у меня большие сомнения. Так-то и джуниор, и сеньор могут сказать "у нас на прошлом проекте использовался X для Y", но навыков Джуна или Мидла (если только это не "сильный мидл, почти сеньор) вряд ли хватит на то, чтобы сопоставить требования, которые были "там" и есть "тут", оценить подводные камни и издержки по внедрению того решения и принять взвешенное решение о целесообразности этого. А у сеньора и опыта прошлых проектов побольше обычно. Так что этот пункт вообще мимо.
Я не о том немного. Если человечество внезапно оказывается уничтоженным, например, гигантским метеоритом, после которого большая часть жизни перестала существовать, то последующие цивилизации через тысячи/миллионы лет могут найти месторождения того же золота с необычно высокой концентрацией на месте нынешних золотохранилищ, некоторых музеев и т.п. Возможно, даже не слишком глубоко от поверхности. На месте нынешних городов вообще будет вся таблица Менделеева в концентрациях сильно выше природных, потому что металлы копились десятилетиями/веками на компактных территориях, при том что транспортировались с обширных территорий. Безусловно, освоить технологии их извлечения будет непросто, но нынешнее человечество с этим справилось, так что нельзя исключать, что и будущее человечество справится. Была бы энергия.
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, но это можно и не дождаться.
Вот конкретно проблему поиска и замены в сотнях файлов XLSX как раз можно было решить за секунды плюс несколько минут на написание PowerShell скрипта, если воспользоваться тем фактом, что XLSX - это zip-архив с XML-ками. Макросы я бы оставил для каких-нибудь более сложных манипуляций.
Абсолютно неадекватные цифры для 2024 г. Даже затрудняюсь сказать, на сколько лет они отстали от рынка.
По-моему, тема сообщений об ошибках неполна без рассказа об их локализации. В теории, там всё легко, локаль настраивается в одном месте, но в деталях вылезают всякие неприятные мелочи, вроде того, что текст сообщения выводится по-русски, а даты в плейсхолдерах форматируется в US-формате.
Всех подробностей не помню, но где-то что-то приходилось подпиливать напильником. И это у нас ещё не было потребности отдавать разным пользователям ответ на разном языке, там бы наверняка ещё что-то вылезло.
Если вы используете стороннюю библиотеку, в которой такие структуры не определены, а вам хочется свой код сделать более лаконичным и наглядным - то использование алиасов позволит это сделать без введения доп. типов, конвертации, нагрузки на GC и т.п. Понятно, что этот вариант использования является довольно узким, и без него вполне можно же жить, ну так это вообще ко всем алиасам относится (тот же `using static ...` всего лишь позволяет чуточку меньше символов писать. Мелкая, иногда приятная, но точно не необходимая "плюшка")
Тут у меня большие сомнения. Так-то и джуниор, и сеньор могут сказать "у нас на прошлом проекте использовался X для Y", но навыков Джуна или Мидла (если только это не "сильный мидл, почти сеньор) вряд ли хватит на то, чтобы сопоставить требования, которые были "там" и есть "тут", оценить подводные камни и издержки по внедрению того решения и принять взвешенное решение о целесообразности этого. А у сеньора и опыта прошлых проектов побольше обычно. Так что этот пункт вообще мимо.
И то, если кто-то глобально на заменил табы на пробелы (или наоборот) где-то ближе к концу проекта
Это довод уровня "у меня нет проф. деформации, а значит её не бывает".
Я не о том немного. Если человечество внезапно оказывается уничтоженным, например, гигантским метеоритом, после которого большая часть жизни перестала существовать, то последующие цивилизации через тысячи/миллионы лет могут найти месторождения того же золота с необычно высокой концентрацией на месте нынешних золотохранилищ, некоторых музеев и т.п. Возможно, даже не слишком глубоко от поверхности. На месте нынешних городов вообще будет вся таблица Менделеева в концентрациях сильно выше природных, потому что металлы копились десятилетиями/веками на компактных территориях, при том что транспортировались с обширных территорий. Безусловно, освоить технологии их извлечения будет непросто, но нынешнее человечество с этим справилось, так что нельзя исключать, что и будущее человечество справится. Была бы энергия.
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, но это можно и не дождаться.