К сожалению, чтобы Вам что-то посоветовать - необходимо узнать Ваш личный "фундамент". Хоть указанная Вами книга и будет полезной (даже с учетом того, что она писалась для MySQL версии 4.х, фундаментально как в СУБД, так и в SQL и в конкретном синтаксисе MySQL последнее, наверно, десятилетие, ничего не менялось), я бы посоветовал следующий алгоритм обучения:
1) Знакомство с основами реляционной алгебры, нормальными формами и реляционной моделью. Без фанатизма, прочтение и осознание статей даже на Википедии хватит за глаза.
2) Знакомство с спецификацией SQL2008. Опять же, без фанатизма. В любом случае, работать Вы будете впоследствии с определенным диалектом языка.
3) Выбор диалекта языка. Подбор литературы (практически любой, за исключением книг из серии "{0} для чайников" и "100 и одно решение для {0}"). На этом этапе важно определиться также с инструментарием, который Вы будете использовать в дальнейшем. Для начала подойдет любой онлайн интерпретатор SQL кода, к примеру
sqlfiddle. Но по мере изучения Вам понадобятся более сложные инструменты.
4) Знакомство с UML. Точнее, если по минимуму, с той частью, которая затрагивает прототипирование БД. SQL и СУБД - это инструменты, которые позволяют автоматизировать процессы бизнес логики. UML позволяет эти процессы описать и на основе этих процессов создать прототип схемы БД, от которого уже можно идти к конкретной реализации.
Итак. Четыре базовых шага выполнены. Дальше все просто, перевариваете информацию и занимаетесь практикой от простого к сложному (в комментариях уже указывали вполне годные наборы задачек). Попутно узнаете особенности программной реализации выбранной Вами СУБД. И внимательно читаете документацию от разработчика. На примере SQLite, у них подробно разобрана семантика запросов:
SQLite CREATE. Под MySQL найдете сами.
Теперь поясню, почему все четыре шага важны.
1) Без базовых фундаментальных знаний вы просто не поймете, почему, к примеру, в ячейке столбца номера нельзя указывать два номера телефона, или как работают ограничения на целостность данных.
2) Хоть диалекты SQL и отличаются от стандарта SQL:2008, следует понимать, что знание стандарта позволит Вам в случае необходимости переключиться с одной СУБД на другую. Также, хорошая реляционная SQL СУБД должна быть совместима с этим стандартом априори.
3) Тут на Ваш вкус. Посмотрите изложение автора перед покупкой, посмотрите списки того или иного программного обеспечения. Но факт остается фактом, что прочтение только стандартов, мануалов и официальной документации - путь явно не для всех. Кому-то просто необходимо "художественное" изложение, да и просто из книг можно почерпнуть реальные примеры из опыта автора.
4) Надо понимать, что реляционные СУБД всего лишь инструмент для хранения и обработки данных, обеспечивающий определенные бизнес-процессы определенной предметной области. И под бизнес-процессами следует понимать не как какую-то эфемерную для простого человека вещь, а то, что закладывается под этим словом в оригинальном языке, т.е. совокупность процессов\действий, направленных на создание продукта\предоставление услуги. А средства UML позволяют все это описать в стандартизированной графической форме. Чтобы знать SQL не надо знать UML, не надо знать, что такое и, к примеру, ЖЦ программного продукта. Но со временем, если Вы захотите расти дальше, Вам нужен будет инструмент прототипирования. Также, как если вы дорастете до архитектора БД, вам нужно будет представление о том, как эти БД проектировать, начиная с описания предметной области и заканчивая организационной точкой зрения. Стандарты ГОСТ 34.601-90 и ISO/IEC 12207:2008.
Я, как и многие, начинал с какого-то полу прочитанного учебника и примеров из сети. Сейчас я понимаю, что просто потратил время практически впустую. Как ни странно, хоть и принято ругать наше образование, но список курсов для специальностей "ПИ" подобран не просто так. Помимо самого языка следует знать математический "бэкенд" и как его использовать для реализации задач предметной области. Я отношусь к SQL потребительски, это не мой основной язык, но сейчас я понимаю, что если бы уделил ему больше внимания не как языку, а, в первую очередь, как к одному из инструментов СУБД, работающих на основе реляционной алгебры для обеспечения бизнес-процессов, я бы избежал кучу потерянного времени, костылей и ошибок. Надеюсь, мой ответ будет Вам полезен.
Простой
