Использование конструкции distinct актуально не только для выбора уникальных записей. Это хороший способ тестирования приложения. Основная семантическая нагрузка на ключевое слово запроса select distinct MySQL - выбрать только те записи, в которых указанное поле имеет уникальное значение.
Можно использовать несколько полей в одном запросе. Можно объединять поля функциями MySQL, применять дополнительные условия в выборке и сортировке. Использовать конструкцию group by тоже допустимо, но нужно учитывать возникающие при этом неопределённости.
Базовые положения и синтаксис
Вам будет интересно:Ввод и вывод в Python. Input и print
Проверка и оптимизация: select distinct - один из самых востребованных способов достижения желаемого. Показательный пример - таблица, содержащая 99 999 записей, которые сформированы случайным образом из трёх массивов:
Формирование тестовой таблицы ex_workers выполнено посредством функции PHP rand (0,10). В каждом массиве ровно 11 элементов. Естественно, что равномерно распределённая случайная величина на количестве записей 99 999 не может допустить хотя бы одно отсутствие first_name на всех last_name и наоборот.
Разумеется, вероятность остаётся, но для каждого уникального имени в массиве $aWorkersF, скорее всего, будет ровно одиннадцать вариантов $aWorkersL. В данном случае в целях тестирования сомнения в исходном наборе данных, как и многократная его генерация - хорошее решение. Идеальные наборы данных - не самое лучшее средство проверки алгоритмов.
Результаты исполнения запросов (1) и (2) - первая и вторая колонки - показывают, что действительно для каждого уникального значения first_name есть одиннадцать значений last_name и наоборот. При этом крайняя правая колонка длиннее одиннадцати строк и имеет 121 строку - при запросе (3) и запросе (4).
Перечисление полей distinct `first_name`, `last_name` эквивалентно distinct concat (`first_name`, `last_name`). Однако это не общий случай, а частное решение.
Основной смысл запроса MySQL select c distinct
Обычная практика: в таблицах всегда есть повторяющиеся поля. Без этого существенного обстоятельства реляционные базы данных просто не существуют. В примере таблица содержит ключевое поле i_status и его смысл w_status. Это должность, которую занимает работник.
В идеале поля i_status и w_status должны быть оформлены в виде отдельной таблицы, а в таблице ex_workers должно остаться только ключевое поле i_status, по которому всегда можно получить наименование должности. Здесь именно такое решение приведено в качестве примера.
Выполнив запрос select distinct на этих двух полях, можно получить все необходимые данные для формирования селектора на веб-странице. Такой селектор позволит выбирать отображаемых сотрудников по занимаемым ими должностям. Это может быть не селектор, а шапка таблицы или ось графика статистики востребованности работников по той или иной специальности.
Нельзя сказать, что основной смысл выбора уникальных записей - это исключительно селекторы, шапки таблиц или оси координат, но это чрезвычайно частое назначение и употребление конструкции select distinct.
Уникальность на динамических данных
Обработка информации - это во многом поиск нужного для принятия правильного решения. Анализ условий можно проводить средствами PHP или другого языка программирования, но, как правило, вся первичная информация сразу записывается в таблицы базы данных. Это уже давно не традиция, а нормальная память для современного сайта. Память в формате реляционной базы данных - отличное и практичное решение.
У конструкции select distinct появляется обширная сфера применения - принятие безусловных решений, если проектировать создание динамических таблиц в процессе работы сайта, например:
- парсинг страниц;
- отслеживание поведения посетителей;
- формирование периметра безопасности путём анализа отклонений от предустановленного (допустимого) характера действий сотрудников.
Планируя простые алгоритмы анализа поступающей информации, записывая первичный результат в таблицу, можно всегда иметь адекватное решение по простому запросу select distinct.
Простота таблиц и сущность реляционной логики
Когда-то программирование и создание баз данных напоминало строительство железных дорог и гостировалось. В основном этот вариант прогресса в научно-технической отрасли был прерогативой социалистической экономики, но и Кремниевая долина тоже успела отличиться в этом вопросе.
Сегодня - чем проще, тем лучше. Всё реже стали появляться вопросы о том, как сделать select distinct на десятке полей из нескольких таблиц одновременно. Квалифицированная разработка стала относиться к созданию баз данных с предельно простой точки зрения: если один разработчик сделал базу данных или запрос к таблице, то другой разработчик должен понять сделанное с полуслова.
Если для понимания организации данных и выборки информации нужно предпринимать хоть какие-то заметные умственные или временные усилия - это объективное основание пересмотреть результаты выполненной работы.
