Конечно, сам по себе код не меняется, однако, в рамках регулярного цикла разработки изменение кода неизбежно и любое вмешательство несет риск ошибок. Предложение переписывать запрос целиком при каждом изменении задачи или обнаружении ошибки кажется радикальным и небезопасным. Реорганизация существующей логики зачастую приводит к большему количеству багов, чем простая корректировка текущего кода. Необходимо тщательно анализировать изменение и бережливо рефакторить.
Базовые принципы и стандарты служат опорой для качественной разработки. И вы правильно заметили, слепое следование этим принципам может ограничивать творческий подход. Необходимо соблюдать баланс, предложенный вами вариант с использованием cross join может в некоторых случаях оказаться производительнее для конкретного решения. Главное осознавать последствия каждого решения и проводить тестирование.
По поводу анализа внешних ключей, ваш комментарий звучит так, будто я предложил отказаться от изучения структуры БД вовсе. Напротив, я пишу о том, что в случае указания связей в самом запросе анализ проводить проще.
Буду рад продолжить обсуждение, если возникнут дополнительные вопросы или возражения.
Код постоянно меняется, исправлять потом так же нужно будет в нескольких местах - вероятность ошибки возрастает.
Исправленный запрос корректен с точки зрения вывода информации, неправильность заключается в использовании литералов и их дубликация в коде. Бинд Параметр в двух местах с привязкой одного значения куда ни шло, но встает вопрос сопровождаемости. Смотреть внешние ключи, чтобы проанализировать запрос - такое себе удовольствие.
Исключения всегда могут быть, если это оправдано, но статья про базовые принципы.
Спасибо за обратную связь и определение селективности. У меня таблица из двух столбцов и объяснение селективности на ее примере. В статье не раскрывается понятие индексов и их виды.
Исправленный запрос корректен, но подходит только для ручных выгрузок. Материал направлен на разработчиков, в коде такой вариант писать будет проблематично и неправильно. Вы нарушаете связь между таблицами и добавляете сложность в исправлении запроса, а в случае большого запроса с множеством таблиц и связей легко будет допустить ошибку и запутаться в разборе.
Рад, что мы достигли взаимопонимания и спасибо за ценные комментарии!
Спасибо за конструктивную критику!
Конечно, сам по себе код не меняется, однако, в рамках регулярного цикла разработки изменение кода неизбежно и любое вмешательство несет риск ошибок. Предложение переписывать запрос целиком при каждом изменении задачи или обнаружении ошибки кажется радикальным и небезопасным. Реорганизация существующей логики зачастую приводит к большему количеству багов, чем простая корректировка текущего кода. Необходимо тщательно анализировать изменение и бережливо рефакторить.
Базовые принципы и стандарты служат опорой для качественной разработки. И вы правильно заметили, слепое следование этим принципам может ограничивать творческий подход. Необходимо соблюдать баланс, предложенный вами вариант с использованием cross join может в некоторых случаях оказаться производительнее для конкретного решения. Главное осознавать последствия каждого решения и проводить тестирование.
По поводу анализа внешних ключей, ваш комментарий звучит так, будто я предложил отказаться от изучения структуры БД вовсе. Напротив, я пишу о том, что в случае указания связей в самом запросе анализ проводить проще.
Буду рад продолжить обсуждение, если возникнут дополнительные вопросы или возражения.
Код постоянно меняется, исправлять потом так же нужно будет в нескольких местах - вероятность ошибки возрастает.
Исправленный запрос корректен с точки зрения вывода информации, неправильность заключается в использовании литералов и их дубликация в коде.
БиндПараметр в двух местах с привязкой одного значения куда ни шло, но встает вопрос сопровождаемости. Смотреть внешние ключи, чтобы проанализировать запрос - такое себе удовольствие.Исключения всегда могут быть, если это оправдано, но статья про базовые принципы.
Спасибо за обратную связь и определение селективности. У меня таблица из двух столбцов и объяснение селективности на ее примере. В статье не раскрывается понятие индексов и их виды.
Исправленный запрос корректен, но подходит только для ручных выгрузок. Материал направлен на разработчиков, в коде такой вариант писать будет проблематично и неправильно. Вы нарушаете связь между таблицами и добавляете сложность в исправлении запроса, а в случае большого запроса с множеством таблиц и связей легко будет допустить ошибку и запутаться в разборе.