Пишем на SQL

Друзья, спасибо за активное участие! Вижу, что не мало получилось неправильных ответов. Я сделаю небольшое разъясняющее видео по этой последней задаче! 👌 Постараюсь объяснить!

Всем хорошего понедельника! Пока едете на работу (если Вы не за рулём)  предлагаю решить ещё одну задачу на поиск ошибки в SQL-запросе. Запрос ниже должен вывести список клиентов (без дублирующихся строчек), которым ни разу не выставляли счёт. SELECT c.CLIENT_ID,                c.CLIENT_NAME,                c.CLIENT_INN   FROM CLIENTS c    LEFT JOIN INVOICES i       ON c.CLIENT_ID = i.CLIENT_ID WHERE i.CLIENT_ID IS NULL

Друзья, поздравляем всех с праздником, с первым сентября! Успехов в постижении новых нужных знаний и совершенствовании умений! Поздравления не только для школьников и студентов, но и для нас! Мы тоже учимся! И это правильный путь!

Дорогие друзья, спасибо Вам за приятные отзывы, которые Вы оставляете нам после прохождения курса 🙏 Конечно, обучение - это трудоёмкий процесс и Вам требуется много времени и сил! Спасибо за Вашу целеустремлённость, стремление и за такую обратную связь!

Спасибо за активное участие в поиске возможной ошибки! Как вы уже поняли, она всё же есть. И ошибки такого вида, к сожалению, иногда допускают и действующие SQL-специалисты. Проблема заключается в том, что для выполнения этого запроса, Ораклу придётся выполнить неявное преобразование. Функция SYSDATE возвращает дату (со временем), функция to_date служит, чтобы ИЗ ТЕКСТА, согласно указанной маске, получать дату. Но ведь SYSDATE итак дата (хоть и со временем), а не текст! Значит, чтобы функция to_date отработала, значение SYSDATE должно быть вначале преобразовано в текст из даты (чтобы to_date сделала из текста опять дату). Терерь не запутаться🙂: вот из текста в дату to_date преобразовывает по маске 'dd.mm.yyyy', а дата в текст в нашем примере преобазовывается Ораклом неявно и без маски. Подробнее как раз этот случай и способ его решения описал здесь: https://dzen.ru/a/Y1qCKnSWlzaLrq1C Посмотрите, пожалуйста, этот мой небольшой пост!😌 Ошибки неявного преобразования тем и опасны, что один и тот же SQL-код у кого-то правильно работает, а у другого - может возвращать неверные данные и даже на основе них могут приниматься важные решения! Хорошо ещё если выскочит SQL-ошибка, благодаря чему можно будет найти проблему неявного преобразования. Хуже, если они такие ошибки остаются незамеченным. ORACLE принимает решения как по-умолчанию представлять дату (если не указан формат преобразования), опираясь на NLS параметры, которые определяются при создании подключения к базе данных. И из-за этого автоматическое и без ведома преобразование даты может делаться по-разному. Преобразование даты в текст или текста в дату должно делаться всегда согласно указываемому формату. И никогда неявно. В среду будем разбирать ещё один SQL-код! 😀

Всем доброго понедельника! В следующей задаче предположите, пожалуйста, есть ли ошибка в SQL-запросе. Приводимый ниже запрос должен показывать товары из таблицы GOODS, срок годности которых истекает сегодня. Поле EXPIRE_DATE таблицы GOODS имеет тип DATE и хранит в себе дату срока годности (без времени).

Всем доброй пятницы и хороших выходных! Давайте разбирать какой из ответов в предыдущей задаче был правильный! Вначале, конечно, должен сообщить, что для решения задачи требовалось знание подзапросов. Если Вы ещё не знакомы с этой темой, то лучше вначале изучить её и затем снова вернуться к этой задаче. Итак, нам нужно было вывести филиалы, в которых есть хотя бы один менеджер. Поэтому для каждого филиала подзапоосом и проверяется наличие (существование) менеджера с его FILIAL_ID. Проблема в том, что подзапрос не связан с внешним запросом. Была допущена ошибка, которую часто совершают начинающие SQL-специалисты. Тут я подробнее об этом написал: https://dzen.ru/a/YrdWwBahoEyqTK_S Когда Вы разберёте эту ошибку, то с большей вероятностью не допустите её при написании SQL кода! Учимся на чужих ошибках! Будьте как SQL-антивирус:) Находите баги и в чужих SQL-запросах.

Добрый день, друзья! Все знаем, что с опытом не только начинаешь меньше делать ошибок при написании SQL-запросов, но и приобретаешь навык быстро находить ошибки в чужом SQL-коде. Следующих несколько задач предлагаю посвятить поиску ошибок в запросах, написанных другими специалистами. Задача первая: В базе данных есть таблица FILIALS, имеющая столбцы FILIAL_ID и FILIAL_NAME, и имеющая три записи. Также есть таблица менеджеров MANAGERS, в которой есть внешний ключ - столбец FILIAL_ID, ссылающийся на таблицу филиалов. Известно, что в таблице филиалов точно есть один филиал, для которого нет ни одного менеджера в таблице MANAGERS. Филиал новый и туда не успели ещё найти сотрудников, но запись в таблице уже есть. Написанный запрос ниже должен показывать список филиалов, в которых есть хотя бы один сотрудник. Почему запрос показывает все три филиала, хотя должен показывать два?

Здравствуйте, друзья! Очень приятно Ваше активное участие в решении присланной задачи! Все Ваши работы проверил и отметил лайком 👍 те, которые счёл правильными. Из 11 присланных работ 9 будут правильно выдавать номера заказов с некорректной нумерацией коробок и 2 работы было бы здорово немного доработать. Ещё раз спасибо за активное участие и хороших выходных!🙂💪

Как насчёт новой задачки по SQL посложнее? Готовы? Тогда задание следующее: в базе данных есть таблица ORDER_BOXES в которой определено по какому заказу сколько коробок оформлено в доставку, а также указано сколько в каждой коробке штук товара и прочая не относящаяся к задаче информация. Таблица имеет следующие интересующие нас поля: ORDER_NUM (номер заказа) BOX_NO (номер коробки заказа). Напомню, что другие столбцы нам сейчас не нужны. Итак, в таблице лежат данные вида: ORDER_NUM BOX_NO 1 1 1 2 2 1 3 1 Данные выше означают, что по заказу с номером 1 есть коробка с номером 1 и есть коробка с номером 2, то есть всего две коробки. Заказы с номерами 2 и 3 имеют по одной коробки. Чтобы проще понять суть и важность задачи приведу ошибочные данные этой таблицы: ORDER_NUM BOX_NO 4 1 4 3 В примере выше в заказе под номером 4 есть номера коробок 1 и 3, но нет 2. То есть если есть коробка с номером 3, то точно должны быть предыдущие номера коробок этого заказа, начиная с одного. Если заказ под номером 4 должен быть доставлен двумя коробками (а не тремя), то правильным было бы в столбце BOX_NO иметь значения 1 и 2. Ниже ещё один пример ошибочных данных: ORDER_NUM BOX_NO 5 1 5 1 5 1 Заказ под номером 5 разбит на три коробки 📦. Правильно было бы иметь в столбце BOX_NO значения 1, 2 и 3. И теперь, наконец, озвучку требования к задаче. На языке SQL требуется написать запрос, показывающий номера заказов с проблемной нумерацией коробок (с отсутствующими номерами коробок или с номерами дублями). Описание решения выложу тут немного позже! С нетерпением буду ждать сначала Ваши предложения решения!

Доброго понедельника, друзья! Всем хорошего начала рабочей и учебной недели! Сегодня с меня сразу две задачи по SQL: одна будет простая (для начинающих) и одна посложнее (для гуру)!

Доброй пятницы! Спасибо всем, кто принял участие в разгадывании филворда по SQL. Я дополнил свой пост, опубликовал решение.

КАК НАЙТИ В СЕБЕ СИЛЫ И УВЕРЕННО ОВЛАДЕТЬ SQL "У каждого взрослого человека всегда много дел" Дмитрий Петров, лингвист, полиглот Aller Anfang ist schwer (любое начинание сложно), немецкая поговорка Всегда трудно начинать что-то новое. Переживания из-за невладения навыком работы с базами данных и незнания языка SQL могут усугубляться страхом его изучения. Как это всё выучить? И не просто выучить, а ещё и начать хорошо разбираться в этом? А вдруг я не смогу найти работу, ведь везде требуются сотрудники уже с опытом работы? Эти и другие страхи возникают постоянно. Но бояться не надо! Язык SQL не сложный! - "Конечно, тебе легко говорить". - Скажешь ты. - "Ведь ты его знаешь". - "Да, знаю. И так же как и ты, когда то впервые его увидел". А ещё я практически сразу понял насколько он прост и лёгок в понимании! Итак, языку SQL и существенным навыкам работы с базами данных можно обучиться за довольно короткое время! А качественное обучение (или самообучение) с обязательной практикой может дать хороший результат! А чтобы начать совсем хорошо в нём разбираться, нужно прорешать множество типичных и каверзных задач. Здесь, конечно, нужен или опыт или нужны хорошие курсы. В своём курсе по SQL и базам данных на простых примерах я проведу тебя через многие практические сложности! Мы научимся решать любые задачи на языке SQL. Научимся видеть потенциальные ошибки в существующем коде и оптимизировать его. Можно реально примерно за месяц (если учиться не торопясь, уделяя час в день) "прокачать" знания языка SQL и навыки работы с базами данных с нуля до уровня специалиста с трёхлетним стажем! Вот так! Я совсем не уговариваю тебя придти ко мне на курс, но был бы тебе очень рад! Мне уже повезло, что ты читаешь этот пост и я могу ещё кое что тебе рассказать! Итак, язык SQL очень прост. Ты можешь ему научиться. Это аксиома (не требует доказательств). - Я знаю. Ты можешь! Ицхак Пинтосевич. Автор множества книг по развитию личности. Итак, SQL тебе под силу! Теперь осталось разобраться как найти на него время и силы. У тебя, возможно, есть семья, дети. Есть работа, которая отнимает основное продуктивное время, есть друзья, которым хоть пол часа в день времени, но уделить нужно (вотсап, вконтакте, одноклассники,..). Вобщем - день занят. И так каждый день! А в выходные надо отдохнуть, ведь всю неделю ты работал как мог! - "У меня есть максимум час в неделю!" - скажешь ты. - "Отлично! С этого и давай начинать!" Час в неделю это лучше, чем ничего. "Большого слона можно съесть по кусочкам", народная мудрость Итак, если у нас есть час в день, то считай, что SQL мы выучим! Да, да! Тратя по-немногу времени на нужный навык, ты, в конце концов, его освоишь! И даже это не растянется на очень долго! Изучай и практикуй! Начни хоть с часу в неделю, ты заметишь, что ты начнёшь в этом разбираться, а через некоторое время тебе это понравится и ты сможешь находить на это больше времени! Незаметно для себя ты овладеешь SQL и обучишься навыкам работы с базами данных! Буду рад, если поделишься своей историей как ты смог найти время и силы на язык SQL!

Всем хорошего понедельника! Давайте немного повторим типы данных столбцов таблиц. В чем разница между CHAR и VARCHAR. Оба типа предназначены для хранения алфавитно-цифровой информации. Основное отличие состоит в том, что тип данных CHAR имеет фиксированную длину для хранящихся в нём значений, в то время как VARCHAR поддерживает переменную длину. Если значение, сохраняемое в CHAR, имеет меньшую длину, то к нему справа будут добавлены пробелы. К значению, сохраняемому в тип VARCHAR, если оно меньше максимально установленного, пробелы справа добавлены не будут.