Нужна помощь
- Автор темы parolex
- Дата начала
Цитата(parolex @ 21 Ноября, 2017, 17:08)
корректно дёрнуть всё по 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
;
корректно дёрнуть всё по 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
;
- Сообщения
- 525
- Реакции
- 15
- Репутация
- 21
parolex
ваша проблема в архитектуре, поэтому любые сложные выборки только через такие вот костыли.
Читайте про нормализацию баз данных
ваша проблема в архитектуре, поэтому любые сложные выборки только через такие вот костыли.
Читайте про нормализацию баз данных
Цитата(killer8080 @ 29 Ноября, 2017, 12:32)
любые сложные выборки только через такие вот костыли
1. сложность там - нулевая
2. это не костыль, а стандартный запрос.
Я бы сказал - даже "библейский" запрос, описанный в книгах задолго до появления mysql-я ...
Причём такие запросы можно слать не только к mysql, но и к ораклу, сайбейзу, эмэс-сиквелу, постгре и прочим дэбэ-пополамам.
Цитата(killer8080 @ 29 Ноября, 2017, 12:32)
ваша проблема в архитектуре
с чего Вы это взяли, что если понадобилась разовая выборка - дело обязательно в архитектуре?
или на 9к строк завести 4 справочника по по 3к строк каждый + кросс-таблицы - 9к * Nсправочников для [де]нормализации.
И это всё ради того, чтоб не писать скрипт в жалких 6 строчечек...
вот - тривиальная задача, описанная в книжке, которая была популярна в начале 90-х, переведена на русский и напечатана издательством "Диалектика"(Киев) в 1997 году
/style_images/CaliV6/read_more.gif
Цитата(из книги. см. на фото выше)
Самоообъединение является другим вариантом объединения на основе равенства. При самообъединении сравниваются значения внутри столбца одной таблицы.
Например, самообъединение можно использовать для поиска авторов, живущих в Окленде, Калифорния, и имеющих одинаковые почтовые коды.
Так как в этом запросе таблица authors объединяется сама с собой, то она выступает сразу в двух ролях. Поэтому для различения этих ролей в списке таблиц предложения FROM ей нужно задать два разных псевдонима - aul и au2. Эти псевдонимы также будут использоваться при задании имен столбцов
а вот задача от ТопикСтартера
Цитата(parolex @ 21 Ноября, 2017, 17:08)
суть в том, как корректно дёрнуть всё по 3-м повторяющимся столбцам
например:фамилия, имя, отчество
ничего не напоминает?
любые сложные выборки только через такие вот костыли
1. сложность там - нулевая
2. это не костыль, а стандартный запрос.
Я бы сказал - даже "библейский" запрос, описанный в книгах задолго до появления mysql-я ...
Причём такие запросы можно слать не только к mysql, но и к ораклу, сайбейзу, эмэс-сиквелу, постгре и прочим дэбэ-пополамам.
Цитата(killer8080 @ 29 Ноября, 2017, 12:32)
ваша проблема в архитектуре
с чего Вы это взяли, что если понадобилась разовая выборка - дело обязательно в архитектуре?
или на 9к строк завести 4 справочника по по 3к строк каждый + кросс-таблицы - 9к * Nсправочников для [де]нормализации.
И это всё ради того, чтоб не писать скрипт в жалких 6 строчечек...
вот - тривиальная задача, описанная в книжке, которая была популярна в начале 90-х, переведена на русский и напечатана издательством "Диалектика"(Киев) в 1997 году
/style_images/CaliV6/read_more.gif
Цитата(из книги. см. на фото выше)
Самоообъединение является другим вариантом объединения на основе равенства. При самообъединении сравниваются значения внутри столбца одной таблицы.
Например, самообъединение можно использовать для поиска авторов, живущих в Окленде, Калифорния, и имеющих одинаковые почтовые коды.
Так как в этом запросе таблица authors объединяется сама с собой, то она выступает сразу в двух ролях. Поэтому для различения этих ролей в списке таблиц предложения FROM ей нужно задать два разных псевдонима - aul и au2. Эти псевдонимы также будут использоваться при задании имен столбцов
а вот задача от ТопикСтартера
Цитата(parolex @ 21 Ноября, 2017, 17:08)
суть в том, как корректно дёрнуть всё по 3-м повторяющимся столбцам
например:фамилия, имя, отчество
ничего не напоминает?
- Сообщения
- 525
- Реакции
- 15
- Репутация
- 21
Цитата(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-м повторяющимся столбцам
например:фамилия, имя, отчество
ничего не напоминает?
напоминает, что автор хочет сделать выборку по людям, и вот тут есть ещё подводный камень, ФИО нельзя использовать как идентификатор отдельно взятого человека, так как эти атрибуты не являются ни уникальными, ни константными. Под одним ФИО может быть несколько разных человек, и если он например сменит фамилию, то его старые записи уже не будут с ним связаны, из-за денормализации (мы ведь храним данные о человеке прямо в таблице с другой сущностью), если же решим эти записи проапдейтить, то можем поломать записи другого человека с тем же ФИО (мы ведь их никак не различаем), ну и о не корректности выборки я уже молчу.
с чего Вы это взяли, что если понадобилась разовая выборка - дело обязательно в архитектуре?
Разве это не очевидно? Поля ФИО - это отдельная сущность, описывающая человека, она должна быть вынесена в отдельную таблицу! Таблица связей тут не обязательна, достаточно добавить связующее поле, например 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-м повторяющимся столбцам
например:фамилия, имя, отчество
ничего не напоминает?
напоминает, что автор хочет сделать выборку по людям, и вот тут есть ещё подводный камень, ФИО нельзя использовать как идентификатор отдельно взятого человека, так как эти атрибуты не являются ни уникальными, ни константными. Под одним ФИО может быть несколько разных человек, и если он например сменит фамилию, то его старые записи уже не будут с ним связаны, из-за денормализации (мы ведь храним данные о человеке прямо в таблице с другой сущностью), если же решим эти записи проапдейтить, то можем поломать записи другого человека с тем же ФИО (мы ведь их никак не различаем), ну и о не корректности выборки я уже молчу.
Цитата(killer8080 @ 9 Декабря, 2017, 3:57)
Разве это не очевидно? Поля ФИО - это отдельная сущность, описывающая человека, она должна быть вынесена в отдельную таблицу! Т
Да ну!
А если это pivot(сводная) таблица?
Или результат какого нибудь etl-процесса?
Цитата(killer8080 @ 9 Декабря, 2017, 3:57)
раз уж читаете умные книжки, то должны знать, что все SQL субд являются реляционными базами данных, а не просто свалками из таблиц.
Я её прочитал в середине 1997 года.
По нынешним меркам не всё в ней однозначно.
20 лет прошло.
И ещё по-поводу "костылей" - гуглите оконные функции.
"partition by", например.
Задумайтесь, для чего они появились.
Цитата(killer8080 @ 9 Декабря, 2017, 3:57)
напоминает, что автор хочет сделать выборку по людям, и вот тут есть ещё подводный камень,
Цитата(parolex @ 21 Ноября, 2017, 17:08)
например:фамилия, имя, отчество
Ключевое слово помечено цветом.
Или запрос м.б. такой:"сгруппировать пофамильно владельцев, купивших утопленные тачки из Краснодара".
Разве это не очевидно? Поля ФИО - это отдельная сущность, описывающая человека, она должна быть вынесена в отдельную таблицу! Т
Да ну!
А если это pivot(сводная) таблица?
Или результат какого нибудь etl-процесса?
Цитата(killer8080 @ 9 Декабря, 2017, 3:57)
раз уж читаете умные книжки, то должны знать, что все SQL субд являются реляционными базами данных, а не просто свалками из таблиц.
Я её прочитал в середине 1997 года.
По нынешним меркам не всё в ней однозначно.
20 лет прошло.
И ещё по-поводу "костылей" - гуглите оконные функции.
"partition by", например.
Задумайтесь, для чего они появились.
Цитата(killer8080 @ 9 Декабря, 2017, 3:57)
напоминает, что автор хочет сделать выборку по людям, и вот тут есть ещё подводный камень,
Цитата(parolex @ 21 Ноября, 2017, 17:08)
например:фамилия, имя, отчество
Ключевое слово помечено цветом.
Или запрос м.б. такой:"сгруппировать пофамильно владельцев, купивших утопленные тачки из Краснодара".
наблюдаю за топиком с интересом
killer8080
вы неправы, от слова совсем
исходная таблица-результат слияния н-го числа таблиц по некоторым условиям. в зависимости от условий меняется кол-во исходных таблиц(3 норма) меняется количество столбцов в результирующей базе.
нет. выборка не по людям.могу поменять фио(раз уж так смущает) на A,B,C или,например, фаза луны, кол-во усов у кошки, кол-во колёс у телеги
суть в том, что отлов некоего повторяющегося события по 3-м параметрам. запрос obscure был допилен мной до необходимого вида за 15 минут и сейчас благополучно 2 раза в неделю срабатывает за 3 секунды, не ложа ПК(гуглил подобные решения, все решения мне ложили машину)
killer8080
вы неправы, от слова совсем
исходная таблица-результат слияния н-го числа таблиц по некоторым условиям. в зависимости от условий меняется кол-во исходных таблиц(3 норма) меняется количество столбцов в результирующей базе.
нет. выборка не по людям.могу поменять фио(раз уж так смущает) на A,B,C или,например, фаза луны, кол-во усов у кошки, кол-во колёс у телеги
суть в том, что отлов некоего повторяющегося события по 3-м параметрам. запрос obscure был допилен мной до необходимого вида за 15 минут и сейчас благополучно 2 раза в неделю срабатывает за 3 секунды, не ложа ПК(гуглил подобные решения, все решения мне ложили машину)
Цитата(parolex @ 11 Декабря, 2017, 10:57)
вы неправы, от слова совсем
тут все правы.
каждый по-своему.
просто killer8080 рассказывает о проектировании и использовании реляционной БД.
я-же пытаюсь абстрагироваться от этого, ибо даже в реляционной БД могут встречаться таблицы без связей(логи, импорт данных из других систем, сложные отчеты, сводные таблицы).
приходится использовать всю мощь SQL-запросов, незаслуженно называемых "костылями",
а в более тяжёлых случая использовать понятия, типа: "Data Mining", "Business Intelligence", "ETL" и прочие "суррогатные ключи" с "олап-кубами".
Кстати, на Ваш 2-й вопрос - пример запроса лежит в личке.
Под спойлером можете посмотреть пример этого запроса, но не для мускуля, а для оракла.
Оцените красоту и изящность платных систем,
/style_images/CaliV6/read_more.gif
Казалась-бы: владелец обоих систем - Oracle.
а какая разница в судьбах...
вы неправы, от слова совсем
тут все правы.
каждый по-своему.
просто killer8080 рассказывает о проектировании и использовании реляционной БД.
я-же пытаюсь абстрагироваться от этого, ибо даже в реляционной БД могут встречаться таблицы без связей(логи, импорт данных из других систем, сложные отчеты, сводные таблицы).
приходится использовать всю мощь SQL-запросов, незаслуженно называемых "костылями",
а в более тяжёлых случая использовать понятия, типа: "Data Mining", "Business Intelligence", "ETL" и прочие "суррогатные ключи" с "олап-кубами".
Кстати, на Ваш 2-й вопрос - пример запроса лежит в личке.
Под спойлером можете посмотреть пример этого запроса, но не для мускуля, а для оракла.
Оцените красоту и изящность платных систем,
/style_images/CaliV6/read_more.gif
Казалась-бы: владелец обоих систем - Oracle.
а какая разница в судьбах...
- Сообщения
- 2,741
- Реакции
- 6
- Репутация
- 83
obscure
Что то в платной ms sql я такого не встречал)
Что то в платной ms sql я такого не встречал)