корректно дёрнуть всё по 3-м повторяющимся столбцам
Цитата(parolex @ 21 Ноября, 2017, 17:08)
вариант с подсчётом кол-ва записей отпадает
это взаимоисключающие условия. Ибо: что-бы узнать повторяется значение или нет - нужно подсчитать повторы
для это и существуют операторы типа count - подсчет, group - группировка, join-объединение и прочие "хэвинги"
в Вашем случае нужно сделать всего 2 вещи: 1. определить дубликаты 2. за-джойнить найденное в пп.1 с остальной таблицей.
пример пример поиска дубликатов с последующим самообъединением:
select duobles.last_name, duobles.first_name, duobles.midle_name, yt.column1, yt.column18 from (SELECT last_name, first_name, midle_name FROM your_table GROUP BY last_name, first_name, midle_name HAVING COUNT(*) > 1) as duobles -- определяем дубликаты присваиваем им алиас(псевдоним) - "duobles" join your_table as yt on yt.last_name = duobles.last_name -- джойним дубликаты с таблицей алиас для "your_table" - "yt" and yt.first_name = duobles.first_name and yt.midle_name = duobles.midle_name ;
любые сложные выборки только через такие вот костыли
1. сложность там - нулевая 2. это не костыль, а стандартный запрос. Я бы сказал - даже "библейский" запрос, описанный в книгах задолго до появления mysql-я ... Причём такие запросы можно слать не только к mysql, но и к ораклу, сайбейзу, эмэс-сиквелу, постгре и прочим дэбэ-пополамам.
Цитата(killer8080 @ 29 Ноября, 2017, 12:32)
ваша проблема в архитектуре
с чего Вы это взяли, что если понадобилась разовая выборка - дело обязательно в архитектуре?
или на 9к строк завести 4 справочника по по 3к строк каждый + кросс-таблицы - 9к * Nсправочников для [де]нормализации. И это всё ради того, чтоб не писать скрипт в жалких 6 строчечек...
вот - тривиальная задача, описанная в книжке, которая была популярна в начале 90-х, переведена на русский и напечатана издательством "Диалектика"(Киев) в 1997 году
Цитата(из книги. см. на фото выше)
Самоообъединение является другим вариантом объединения на основе равенства. При самообъединении сравниваются значения внутри столбца одной таблицы. Например, самообъединение можно использовать для поиска авторов, живущих в Окленде, Калифорния, и имеющих одинаковые почтовые коды. Так как в этом запросе таблица authors объединяется сама с собой, то она выступает сразу в двух ролях. Поэтому для различения этих ролей в списке таблиц предложения FROM ей нужно задать два разных псевдонима - aul и au2. Эти псевдонимы также будут использоваться при задании имен столбцов
а вот задача от ТопикСтартера
Цитата(parolex @ 21 Ноября, 2017, 17:08)
суть в том, как корректно дёрнуть всё по 3-м повторяющимся столбцам например:фамилия, имя, отчество
Группа: Silver Member
Сообщений: 525
Регистрация: 03.03.10 Авторитет: 21
Вне форума
Предупреждения: (0%)
Цитата(obscure @ 30 Ноября, 2017, 11:07)
с чего Вы это взяли, что если понадобилась разовая выборка - дело обязательно в архитектуре?
Разве это не очевидно? Поля ФИО - это отдельная сущность, описывающая человека, она должна быть вынесена в отдельную таблицу! Таблица связей тут не обязательна, достаточно добавить связующее поле, например person_id, ссылающееся на первичный ключ соответствующей таблицы.
Цитата(obscure @ 30 Ноября, 2017, 11:07)
или на 9к строк завести 4 справочника по по 3к строк каждый + кросс-таблицы - 9к * Nсправочников для [де]нормализации. И это всё ради того, чтоб не писать скрипт в жалких 6 строчечек...
Совершенно верно и количество строчек в запросе тут не причём, я вообще не понимаю, почему нужно искать оправдание нормализации? Оправдывать как раз таки нужно денормализацию, в отдельных случаях она необходима для улучшения производительности, но в данном случае она возникла от незнания ТС основ, о чём ему вы почему то не сочли нужным сказать, И что вас так напугало в дополнительных таблицах? Объём места на диске? А как насчёт дублежа данных, и лишних полях?
Цитата(obscure @ 30 Ноября, 2017, 11:07)
вот - тривиальная задача, описанная в книжке, которая была популярна в начале 90-х, переведена на русский и напечатана издательством "Диалектика"(Киев) в 1997 году
раз уж читаете умные книжки, то должны знать, что все SQL субд являются реляционными базами данных, а не просто свалками из таблиц. И о НФ в той книжке наверно тоже написано
Цитата(obscure @ 30 Ноября, 2017, 11:07)
а вот задача от ТопикСтартера Цитата(parolex @ 21 Ноября, 2017, 17:08) суть в том, как корректно дёрнуть всё по 3-м повторяющимся столбцам например:фамилия, имя, отчество
ничего не напоминает?
напоминает, что автор хочет сделать выборку по людям, и вот тут есть ещё подводный камень, ФИО нельзя использовать как идентификатор отдельно взятого человека, так как эти атрибуты не являются ни уникальными, ни константными. Под одним ФИО может быть несколько разных человек, и если он например сменит фамилию, то его старые записи уже не будут с ним связаны, из-за денормализации (мы ведь храним данные о человеке прямо в таблице с другой сущностью), если же решим эти записи проапдейтить, то можем поломать записи другого человека с тем же ФИО (мы ведь их никак не различаем), ну и о не корректности выборки я уже молчу.
исходная таблица-результат слияния н-го числа таблиц по некоторым условиям. в зависимости от условий меняется кол-во исходных таблиц(3 норма) меняется количество столбцов в результирующей базе.
нет. выборка не по людям.могу поменять фио(раз уж так смущает) на A,B,C или,например, фаза луны, кол-во усов у кошки, кол-во колёс у телеги суть в том, что отлов некоего повторяющегося события по 3-м параметрам. запрос obscure был допилен мной до необходимого вида за 15 минут и сейчас благополучно 2 раза в неделю срабатывает за 3 секунды, не ложа ПК(гуглил подобные решения, все решения мне ложили машину)
тут все правы. каждый по-своему. просто killer8080 рассказывает о проектировании и использовании реляционной БД.
я-же пытаюсь абстрагироваться от этого, ибо даже в реляционной БД могут встречаться таблицы без связей(логи, импорт данных из других систем, сложные отчеты, сводные таблицы). приходится использовать всю мощь SQL-запросов, незаслуженно называемых "костылями", а в более тяжёлых случая использовать понятия, типа: "Data Mining", "Business Intelligence", "ETL" и прочие "суррогатные ключи" с "олап-кубами".
Кстати, на Ваш 2-й вопрос - пример запроса лежит в личке.
Под спойлером можете посмотреть пример этого запроса, но не для мускуля, а для оракла. Оцените красоту и изящность платных систем,
Казалась-бы: владелец обоих систем - Oracle. а какая разница в судьбах...