Comments 42
а) это совсем уже азы, которые тысячу раз переписанные
б) неправильная у вас связка: комната и человек — это атомарные сущности (в примере). телефоны уникальны и закрепляются за комнатой и человеком, поэтому именно таблица телефонов должна содержать айдишники человека и комнаты. phoneid излишнее, так как номер телефона и без того уникален.
б) неправильная у вас связка: комната и человек — это атомарные сущности (в примере). телефоны уникальны и закрепляются за комнатой и человеком, поэтому именно таблица телефонов должна содержать айдишники человека и комнаты. phoneid излишнее, так как номер телефона и без того уникален.
Ну, теоретически наверное телефон может быть параллельным или просто «висеть» на нескольких людях (и у человека может быть несколько номеров, например городской + внутренний + мобильный и т.д.). Тогда получаем вообще M:N связь с промежуточной таблицей, на которой и тренируем навыки JOIN'инга.
В остальном согласен, унылая статья получилась
В остальном согласен, унылая статья получилась
Для тех, кто знаком с SQL хотя бы поверхностно, статья кажется унылой. Но судя по тому, что статью добавляют в избранное, то такие статьи «для начинающих» кому-то интересны. Может пора открыть на хабре блог «Для новичков»? Наверняка ведь есть темы, в которых и Вы новичок.
а вот это очень хорошая задумка. с таким рейтингом хабра можно было бы получать большинство переходов по нубовым статьям именно на хабр
Предлагаете туда постить все, что уже есть в мануалах?
Редкий новичок читает мануалы. Увы, но мало у кого сейчас есть рефлекс «Не знаешь — погугли» =(
Не обязательно. Например, человек не знаком с Java Script, но очень хочет с ним познакомиться. Лично у меня сразу возникает куча вопросов: где посмотреть синтаксис языка, где прочитать про тонкости и нюансы, какую IDE использовать, как отлаживать, какие типичные ошибки совершают новички и как пишут профессионалы, где применим язык и тд и тп. Конечно, можно самому рыть по интернетам (что несомненно очень полезно для новичка), но как сказал чуть выше romy4, благодаря рейтингу Хабра, люди, которые ищут статьи для новичков будут находить их именно на Хабре. А в этих статьях такие же новички или может даже профессионалы будут делиться опытом, а также рассказывать о подводных камнях, плюсах и минусах и так далее.
Вы тут видите тонкости и нюансы? Основы легко гуглятся, это не проблема. Тот же javascript.ru уже содержит все, что нужно.
Понимаете, статьи для новичков это полезно, это здорово! Но ведь они должны содержать что-то новое, а не переписанное содержимое мануалов. Иначе в комментах самым полезным будет что-нить типа RTFM
Понимаете, статьи для новичков это полезно, это здорово! Но ведь они должны содержать что-то новое, а не переписанное содержимое мануалов. Иначе в комментах самым полезным будет что-нить типа RTFM
Согласен с Вами. Скорее всего данная статья действительно не претендует на полноценную статью. Но ведь есть статьи, которые достойны прочтения.
ньюансы есть. те же индексы. зачем они, как они и почему о них забывают. в мануалах пока прочитаешь об этом, то будет поздно (для дела поздно). а этому надо изначально обучать
Так напишите об индексах, о производительности и оптимизации! Это будет интересно, полезно. По аналогии с PHP — все норовят описать установку PHP+MySQL+Apache, но никто не стремится рассказать о тонкостях конфигурации, настройках безопасности и т.д.
Статья, даже если она для новичков, должна быть актуальной и полезной.
Статья, даже если она для новичков, должна быть актуальной и полезной.
на хабре уже были статьи об индексах, по оптимизации производительности, и повторяться не очень хотелось бы. А вот для нубов слепить годный пример было бы хорошо.
только куда постить такой цикл статей? можно было бы рассказать и показать на реальном проекте с нуля.
только куда постить такой цикл статей? можно было бы рассказать и показать на реальном проекте с нуля.
Реальный проект новичок не поймёт. В этом вся проблема, поэтому и в институтах до сих пор на первом курсе на синтетических примерах учат. Реальный проект это advanced уровень, по нему нельзя научиться, по нему можно лишь повысить квалификацию.
Даже в маленьких проектах используется сложный код.
Даже в маленьких проектах используется сложный код.
Пишите в SQL или MySQL, это не проблема, ИМХО.
Вы и правы и нет. Как пример: некоторое время назад присматривал книгу из серии «PHP для чайников», так многие из них, ещё во введении ссылались на примеры с массивами, объектами и прочими прелестями, чего, увы, я не могу назвать «азами для чайников».
Вы можете сказать что такого рода книжки — не мануал, но уж поверьте, многие существующие мануалы выглядят ещё сложнее для полных новичков.
Вы можете сказать что такого рода книжки — не мануал, но уж поверьте, многие существующие мануалы выглядят ещё сложнее для полных новичков.
Эти азы конечно переписаны тысячи раз и книжек по sql тоже море. Тут не поспоришь. Но основа статьи была в том, что надо сесть за консоль, открыть эту станицу и начать вбивать код (не зря здесь соотношение код/текст где-то 1/3), что способствует большей усвояемости. Человек во время обучения видит задачу, которую может решить.
Ну как я и сказал, пример синтетический. Если приводить реальный, то запрос мог получиться сложнее. На мой взгляд 2 join`а это и так много для человека, который их впервый раз увидел.
Мне всегда легче училось на примерах и задачах и не так чтобы они были только в конце главы, а встречались в тексте повсеместно, поэтому решил написать именно в таком стиле.
Ну как я и сказал, пример синтетический. Если приводить реальный, то запрос мог получиться сложнее. На мой взгляд 2 join`а это и так много для человека, который их впервый раз увидел.
Мне всегда легче училось на примерах и задачах и не так чтобы они были только в конце главы, а встречались в тексте повсеместно, поэтому решил написать именно в таком стиле.
Хотя бы учите правильно. Int(5) не означает, что это поле длиной 5 знаков. «Размер» целочисленного поля не влияет на размерность значения, это по сути метаданные.
Вообще, если ставите задачу сформировать учебник для начинающих, пишите отдельные подробные статьи по операторам (сперва SELECT, наверное даже в нескольких частях, потом INSERT, UPDATE, DELETE и т.д.). У Вас сейчас в статье полная каша.
Вообще, если ставите задачу сформировать учебник для начинающих, пишите отдельные подробные статьи по операторам (сперва SELECT, наверное даже в нескольких частях, потом INSERT, UPDATE, DELETE и т.д.). У Вас сейчас в статье полная каша.
Почему сперва SELECT? Что будет выбирать читатель и откуда? Или к статье прилагать дамп на готовую БД?
То что Вы предлагает это обычный учебник, коих много. Как я писал и выше и ниже, цель была не в этом. Подразумевалось что-то вроде «SQL за 30 минут» :D
Про Int(5) спасибо, исправлю, видимо где-то неправильно прочитал, да так и осталось в голове.
То что Вы предлагает это обычный учебник, коих много. Как я писал и выше и ниже, цель была не в этом. Подразумевалось что-то вроде «SQL за 30 минут» :D
Про Int(5) спасибо, исправлю, видимо где-то неправильно прочитал, да так и осталось в голове.
мануал тоже учит в консоли и тоже примеры там весьма синтетически.
вот если учить азам и при этом писать большой проект — это была бы весьма правильная идея.
вот если учить азам и при этом писать большой проект — это была бы весьма правильная идея.
Надо уметь читать между строк.
Цель поста не научить тому, что есть в любой книге по SQL.
Цель — получить инвайт на хабр.
P.S. Краткая инструкция:
Берём учебник, открываем любую главу — пишем пост на хабр, получаем инвайт.
Цель поста не научить тому, что есть в любой книге по SQL.
Цель — получить инвайт на хабр.
P.S. Краткая инструкция:
Берём учебник, открываем любую главу — пишем пост на хабр, получаем инвайт.
Спорить не буду. Инвайт тоже хотелось. Но и писать фигню я сюда не собирался. Более того никто не заставлял меня эту статью публиковать после получения инвайта. Так что наезд немного сомнительный.
Вот мне по работе вдруг понадобилось узнать основы чего либо (perl, sql, настройки апача или нгинкса). Возникает логичный вопрос. Что делать? Открывать man по апачу или найти готовый конфиг с комментариями и по аналогии быстренько сваять свой. Всегда стоит оценивать время потраченное на обучение и частоту использования полученных знаний.
Вот мне по работе вдруг понадобилось узнать основы чего либо (perl, sql, настройки апача или нгинкса). Возникает логичный вопрос. Что делать? Открывать man по апачу или найти готовый конфиг с комментариями и по аналогии быстренько сваять свой. Всегда стоит оценивать время потраченное на обучение и частоту использования полученных знаний.
чёт мне совесть не позволяет так делать. а вот если б был блог «для нубов», я бы с удовольствием туда писал. мой опыт обучения програмингу позволяет хорошо объяснять и делать это на примерах из жизни
У вас нет пользователя с ником quz.
Чем хуже/лучше выборка вида
Чем хуже/лучше выборка вида
select room_number from table3
where phone_id in (
select phone_id from table2 where user_id in (
select user_id from table1 where username = 'quz'))
Да с quz ошибся. Поправил должно было быть qux.
Подзапросы аналогичны только INNER JOIN`ам. Т.е. если подзапрос вернёт пустой результат, то и общий результат тоже будет пустым.
У mysql есть внутренние механизмы оптимизации join`ов (не совсем честное замечание, так как статья по sql а не СУБД, поэтому всё можем меняться от версии к версии и от ПО к ПО).
Ну и не кажется ли Вам что с JOIN`ом запрос читается легче и выглядит короче ;)
Ну и всё надо смотреть от ситуации. На такой маленькой таблице скорость не проверить, но если есть желание, можно добавить туда побольше данных и посмотреть что нам скажет explain.
Подзапросы аналогичны только INNER JOIN`ам. Т.е. если подзапрос вернёт пустой результат, то и общий результат тоже будет пустым.
У mysql есть внутренние механизмы оптимизации join`ов (не совсем честное замечание, так как статья по sql а не СУБД, поэтому всё можем меняться от версии к версии и от ПО к ПО).
Ну и не кажется ли Вам что с JOIN`ом запрос читается легче и выглядит короче ;)
Ну и всё надо смотреть от ситуации. На такой маленькой таблице скорость не проверить, но если есть желание, можно добавить туда побольше данных и посмотреть что нам скажет explain.
Ещё
Не совсем понял про не совсем честное замечание. Если вы про мой пост, то это не замечание а вопрос.
Я не так часто сталкиваюсь с такими выборками(может по этому подзапросы для меня проще), потому и спрашиваю разницу.
quuz остался.Не совсем понял про не совсем честное замечание. Если вы про мой пост, то это не замечание а вопрос.
Я не так часто сталкиваюсь с такими выборками(может по этому подзапросы для меня проще), потому и спрашиваю разницу.
quuz добавляется в запросе «INSERT INTO table1 (username) VALUE ('quuz');», для того чтобы показать разницу между INNER JOIN и LEFT JOIN.
Моё замечание нечестное. Нельзя оперировать понятием производительности отдельно от СУБД, т.е. на разных системах (MySQL, PostgresSQL, Oracle), преимущества по производительности могут колебаться как в одну так и в другую сторону.
Моё замечание нечестное. Нельзя оперировать понятием производительности отдельно от СУБД, т.е. на разных системах (MySQL, PostgresSQL, Oracle), преимущества по производительности могут колебаться как в одну так и в другую сторону.
Не очень понял смысл поста — почему нельзя взять книжку Грабера «Понимание SQL» и прочитать? Она доступна и в электронном виде, и в виде туалетного формата (бумажной книжки) за совсем недорого…
Ну или гуглить по «Краткий курс SQL», википедию глянуть, в конце концов.
Ну или гуглить по «Краткий курс SQL», википедию глянуть, в конце концов.
В википедии обычно команды даются бес связных примеров.
Погуглил. На интуите нужен аккаунт, а он не у всех есть. Другой краткий курс больше чем моя статья и в нём есть вещи, которых я намерено избегал дабы до максимума упростить статью.
Про книги отдельный разговор. Попробуйте в гугле вбить «книги по SQL». Какую из всех полученных Вы будете качать? Я вот не знаю. Но за «Понимание SQL» спасибо, почитаю.
Погуглил. На интуите нужен аккаунт, а он не у всех есть. Другой краткий курс больше чем моя статья и в нём есть вещи, которых я намерено избегал дабы до максимума упростить статью.
Про книги отдельный разговор. Попробуйте в гугле вбить «книги по SQL». Какую из всех полученных Вы будете качать? Я вот не знаю. Но за «Понимание SQL» спасибо, почитаю.
Одна из вещей, которая связана с SQL и очень не нравится новичкам, привыкшим к разжевыванию и пошаговому восприятию — то, что его нужно изучать и понимать (грокать :) большими дозами.
SQL как пиво — менее полулитра не дают нужных вкусовых ощущений. :)
Продолжайте писать статьи, но лучше о чем-нибудь своем, выстраданном. Например, меня в связи с хостингом всегда интересовал вопрос — как управляют нагрузкой на SQL-базу на shared-хостинге.
Ведь любой пользователь при небольшом старании может написать запрос,
которое будет «лупить» прямые произведения поверх CTE и погонять неоптимальными джойнами, в результате чего резко вырастет потребление ЦПУ или дискового IO или всего вместе. Пользуются ли хостеры какими-нибудь средствами, позволяющими отследить жадных до ЦПУ/ диска пользователей и понизить им приоритет или еще как-то порешать ситуацию?
SQL как пиво — менее полулитра не дают нужных вкусовых ощущений. :)
Продолжайте писать статьи, но лучше о чем-нибудь своем, выстраданном. Например, меня в связи с хостингом всегда интересовал вопрос — как управляют нагрузкой на SQL-базу на shared-хостинге.
Ведь любой пользователь при небольшом старании может написать запрос,
которое будет «лупить» прямые произведения поверх CTE и погонять неоптимальными джойнами, в результате чего резко вырастет потребление ЦПУ или дискового IO или всего вместе. Пользуются ли хостеры какими-нибудь средствами, позволяющими отследить жадных до ЦПУ/ диска пользователей и понизить им приоритет или еще как-то порешать ситуацию?
Уважаемый автор, у меня дежа вю. Второй раз за неделю задаю один и тот же вопрос. Какую цель Вы преследовали при написании этой статьи? Это не руководство для начинающих, потому что не дано даже элементарное понятие, что такое база данных, зачем и когда она нужна. Не дано даже описание синтаксиса основных операторов SQL, просто какие-то частные примеры, причем не слишком показательные
И по-существу. А почему у вас в таблицах в роле ключей одни суррогаты? Зачем нужны room_id и phone_id, если в Вашей предметной области не может быть двух одинаковых номеров комнат, а одинаковых номеров телефонов не может быть в природе?
И по-существу. А почему у вас в таблицах в роле ключей одни суррогаты? Зачем нужны room_id и phone_id, если в Вашей предметной области не может быть двух одинаковых номеров комнат, а одинаковых номеров телефонов не может быть в природе?
Я уже тут так много отвечал на вопрос зачем, что немного устал. Я честно думал, что статья будет полезной. Комментарии показывают обратное. Могу принести только свои извинения за то, что потратил Ваше время (это искренне, без сарказма). Все замечания приму к сведению и когда буду писать в следующий раз (не обязательно по этой же теме) постараюсь не допускать тех же ошибок.
Ещё раз повторюсь, что пример синтетический.
Ещё раз повторюсь, что пример синтетический.
Я искренне верю, что Ваши намерения были благородны. Но статьи такого рода не полезны, а скорее даже вредны для начинающих. Объясню почему. Вы пытаетесь ввести читателя в основы языка запросов к реляционным базам данных, но предварительно не даете ему никакого понимания основ самих БД и сразу переходите к таблицам. В связи с этим у начинающего возникнет совершенно неверное представление о проектировании баз данных как таковом. Это как заставлять ученика сначала написать пару-тройку сочинений, а потом учить правилам русского языка. Вы, например, используете оператор JOIN, но при этом молчите о том, что он из себя представляет (на уровне реляционной алгебры), когда его можно использовать, когда нужно, а когда категорически нельзя. В итоге читатель, начинающий изучение баз данных, возьмет на вооружение так называемый «практический» подход и будет создавать БД без понимания своих действий, по шаблону. Это не говоря уже о том, что в Вашем примере допущены такие ошибки проектирования, как ненужные суррогатные ключи, которые тоже вызывают привыкание у новичков.
Простите, если выразился слишком резко, но подобный подход к изучению и его результаты приходится видеть уж слишком часто.
Простите, если выразился слишком резко, но подобный подход к изучению и его результаты приходится видеть уж слишком часто.
Могу по личному опыты сказать, что в 90% случае «индексов много не бывает». Опыт основан на работе в хостинговой компании и оценке работы запросов клиентов пользующихся виртуальным хостингом.
А теперь представьте что данный ман нужен Вам не для того, чтобы начать писать свой код. Было бы как минимум странно если бы Вы решили что можно полноценно учиться на данный статье. А для того, чтобы понять чужой код, хоть в какой-то мере. Например, Вы администрируете сервер и у Вас включены логи медленных запросов. Вам необходимо понятно в какой базе/таблице/поле находится узкое место (напомню что стандартно в логах медленных запросов пишется только пользователь под которым этот запрос выполнялся, но не пишется база).
Поэтому, как я писал выше AgentSmith`у: «всегда стоит оценивать время потраченное на обучение и частоту использования полученных знаний. „
Но в целом Вы, наверное, правы.
А теперь представьте что данный ман нужен Вам не для того, чтобы начать писать свой код. Было бы как минимум странно если бы Вы решили что можно полноценно учиться на данный статье. А для того, чтобы понять чужой код, хоть в какой-то мере. Например, Вы администрируете сервер и у Вас включены логи медленных запросов. Вам необходимо понятно в какой базе/таблице/поле находится узкое место (напомню что стандартно в логах медленных запросов пишется только пользователь под которым этот запрос выполнялся, но не пишется база).
Поэтому, как я писал выше AgentSmith`у: «всегда стоит оценивать время потраченное на обучение и частоту использования полученных знаний. „
Но в целом Вы, наверное, правы.
Для грамотно построенной базы и корректно составленных запросов такие индексы не нужны. В Вашем примере не нужны уж точно.
И AgentSmith конечно прав, но ключевым моментом является понимание чужого кода. А понять чужой код можно только если понимаешь свой. Я на собственном опыте неоднократно убеждался, что невозможно понять, почему один запрос работает быстро, а другой до китайской пасхи, если не понимаешь, как СУБД манипулирует реляционными данными, т.е. как SQL-запрос превращается в выражение реляционной алгебры.
Поэтому если админ нашел узкое место по логам, лучше ему направить эту проблему к специалисту по БД, а не пытаться понять проблему на основании руководств для начинающих
И AgentSmith конечно прав, но ключевым моментом является понимание чужого кода. А понять чужой код можно только если понимаешь свой. Я на собственном опыте неоднократно убеждался, что невозможно понять, почему один запрос работает быстро, а другой до китайской пасхи, если не понимаешь, как СУБД манипулирует реляционными данными, т.е. как SQL-запрос превращается в выражение реляционной алгебры.
Поэтому если админ нашел узкое место по логам, лучше ему направить эту проблему к специалисту по БД, а не пытаться понять проблему на основании руководств для начинающих
Вы меня не правильно поняли. Я же не говорил исправлять после этого запрос. Я сказал просто найти. Более того, медленные запросы, это просто пример.
С каких пор на shared-хостинге появились грамотные базы, запросы и сайты? Большинство из них на готовых CSM, которые не могут предугадать всех моментов. А часть написана школьником Васей между уроков.
Чтобы читать книги не обязательно знать грамматику. Чтобы понять код не обязательно знать как устроен компилятор.
С каких пор на shared-хостинге появились грамотные базы, запросы и сайты? Большинство из них на готовых CSM, которые не могут предугадать всех моментов. А часть написана школьником Васей между уроков.
Чтобы читать книги не обязательно знать грамматику. Чтобы понять код не обязательно знать как устроен компилятор.
> С каких пор на shared-хостинге появились грамотные базы, запросы и сайты?
Согласен. Я имел ввиду, что не надо подобные примеры «плохого тона» вставлять в обучающие примеры, новички подумают, что так и надо.
Но чтобы читать книгу, обязательно знать грамматику. Для этого русский язык в школьной программе. И чтобы понять код, действительно понять, нужно иметь представление о том, как он будет выполняться. Практика всегда должна основываться на твердом знании теории, таково мое мнение
Согласен. Я имел ввиду, что не надо подобные примеры «плохого тона» вставлять в обучающие примеры, новички подумают, что так и надо.
Но чтобы читать книгу, обязательно знать грамматику. Для этого русский язык в школьной программе. И чтобы понять код, действительно понять, нужно иметь представление о том, как он будет выполняться. Практика всегда должна основываться на твердом знании теории, таково мое мнение
Еще могу добавить, что уж раз у нас поля не field1, field2, то и таблицы можно было осмысленно назвать. Начитается нуб такого, а потом будет делать database1 с таблицами table1, table2 и т.д.
Sign up to leave a comment.
Основы SQL на примере задачи