[SQL] с чего начать?

За месяц-полтора надо углубленно изучить сабж

За такой срок его можно выучить наизусть, забыть и снова выучить. Какой диалект интересует?

За месяц-полтора надо углубленно изучить сабж

OMG

Ну если по верхам то http://www.sql.ru/books/books.aspx?g=6&s=0

За такой срок его можно выучить наизусть, забыть и снова выучить.

углубленно? со всей подлежащей под ним математикой? и ты до сих пор не топ менеджер Google? OMG, роисся богата талантами

А там разве какая-то сложная математика? Теория множеств, что еще? Я не стебусь, мне правда интересно.

SQL достаточно простой язык, так что бери любую книгу по «чистому» SQL (не привязанному к какой-либо БД) и учи.

мускул или постгрес, пока не уточнили

углубленно? со всей подлежащей под ним математикой?

Подразумевается что ТС не на тракторе по колхозу ездил, а слегка в теме. Может он на 4GL пишет и sql ему нафиг был не нужен.

слегка в теме

на предыдущем курсе изучали sql на уровне простых запросов

мускул

http://dev.mysql.com/doc/refman/5.5/en/index.html

постгрес

http://www.postgresql.org/docs/9.1/interactive/index.html

Большего не нужно.

Теория множеств, что еще? Я не стебусь, мне правда интересно

Что же тогда люди на 22Мб намусолили в SQL.and.Relational.Theory.2nd.Edition.pdf How to Write Accurate SQL Code, мне правда интересно

Сам sql достаточно прост, я не понимаю почему им не пользуются те, для кого он разрабатывался. Намного интереснее различные средства агрегирования информации. Некоторые диалекты позволяют строить готовые отчеты со сложной структурой, создание которых обычно переносится в приложение (либо ORM, либо незнание возможностей sql разработчиком не позволяет реализовать это средсвами sql).

Ну тогда вообще проблем быть не должно, книжки выше уже посоветовали.

Некоторые диалекты позволяют строить готовые отчеты со сложной структурой

все это платное и ни разу не opensource

Об этом не задумываешься, когда выполняешь свою работу.

Ну и я упор делал на то, что иногда интереснее поломать голову над составлением хитрого запроса, который тебе нарисует готовый отчет, чем банальный sql.

освежи теорию множеств(1 страничка) + описание sql(стандарт)(дайджест без нюансов) +[наряду что вам там давали] книжки вот http://en.wikipedia.org/wiki/Joe_Celko этого дядьки

Сам по себе SQL довольно простой язык. Концепций немного, и все они очень цельные, чистые и прозрачные. Всю идеальность ему портит математическая сухость. Поэтому главная рекомендация такая:
При изучении SQL нужно обязательно делать все примеры и задачи из учебника. Нужно «щупать кончиками пальцев» данные в базе. Без этого SQL просто черствый сухарь, который и в горло не лезет. Учебник при этом подойдёт любой, из серии «для чайников».

Если в дальнейшем планируется работать с «боевой» базой данных, то одного SQL-я уже не хватит. понадобится:

1. Понимание правильного проектирования баз, знание нормальных форм и протчая...
2. Знание особенностей и языковых расширений конкретной СУБД, способов построения быстрых запросов для этой СУБД
3. Знание дополнительных языков, которые СУБД использует для хранимых процедур и триггеров
4. Умение использовать дополнительные управляющие структуры СУБД, типа сиквенсов, индексов, партиций и т.д.
5. Знание структуры конкретной «боевой» БД, назначения основных таблиц и связей
6. Знание предметной области, для которой сделана база данных. Знание того как предметная область представлена в конскретных таблицах конкретной БД

http://www.sql-ex.ru/ - мощный туториал по построению запросов, бесплатной части хватает вполне.

1. Понимание правильного проектирования баз, знание нормальных форм и протчая...
2. Знание особенностей и языковых расширений конкретной СУБД, способов построения быстрых запросов для этой СУБД

И съесть 3-х собак, оптимизируя развесистые запросы, добиваясь отсутствия где-то внутри «фулскана», если только не по последним нескольким строкам. А также не смотря на «простую математику» понять, что часто к желаемому результату можно придти много более чем одним путём, а оптимальный путь может зависеть от безумного количества факторов, не всегда «математического плана», а также от самих данных, причём собственная статистика по ним не всегда позволяет принять БД правильное решение. А потом понять, что в большинстве случаев проще нарастить аппаратные ресурсы, чем оплачивать работу какого-нибудь Oracle DBA ***, но если всё-таки в этом специалисте есть потребность, то... этот специалист чувствует себя очень хорошо ;)

Если интересует теория реляционных БД, то можешь почитать тут, подробно, доступно, и на русском языке.

на предыдущем курсе изучали sql

А теорию вам хорошо читали? Если нет, то ознакомься для начала с книгами К. Дейта «Введение в системы баз данных» и «SQL и реляционная теория. Как грамотно писать код на SQL». Ну и чтение книги «Системы баз данных» Гектора Гарсиа-Молина будет несомненным плюсом. Далее уже работай над конкретной СУБД: для PostgreSQL могу порекомендовать хорошую книгу, автором которой являются супруги Douglas. Книга так и называется «PostgreSQL». Правда, она слегка устарела, поэтому если будешь ее читать одновременно заглядывай в документацию на сайте. По МySQL можно прочитать книги Пола Дюбуа в качестве введения. Ну и однозначно стоит прочитать блог MySQL Performance blog - если мне не изменяет память, то он от авторов Percona Server.

надо углубленно изучить сабж

Что в твоем понимании значит «углубленно»? Проектирование входит в углубленное знание сабжа? Или может углубленное знание - это непосредственно разработка принципиально новой РСУБД? :) В любом случае, Эрик Эванс с его DDD и Скотт В. Эмблер с Рефакторингом баз данных послужат неплохим продолжением изучения сабжа.

Для того чтоб осилить основы и писать работающий код, действитеольно, достаточно любой базовой книги о чистом SQL.

Чтоб писать оптимизированный код, организовывать грамотные быстрые запросы - тут уже нужно глубже вникать в механизмы, структуру БД. На это могут уйти года - это целая наука.

организовывать грамотные быстрые запросы - тут уже нужно глубже вникать в механизмы, структуру БД

Вы, наверняка, хотели сказать организовывать быстрые запросы на плохо спроектированной, чужой БД. Обычно бывает именно так. Для грамотно спроектированной базы запросы пишутся без труда.

На это могут уйти года - это целая наука.

Не надо пугать ТСа, годы это ты загнул.

Обычно бывает именно так. Для грамотно спроектированной базы запросы пишутся без труда.

Ой уморил :)
В нормальной базе нормального проекта кол-во таблиц исчисляется сотнями, а не десятками или единицами.
Даже если (то есть тем более) проектировать по всем правилам нормализации, со справочниками, то обычный рядовой селект зохавывает четыре-пять таблиц.
А чаще всего это селект хитрой статистики в срезе, который при проектировании и не планировался. А значит не пять таблиц а все десять, в самых хитрых комбинациях.
А проектируй-не проектируй, всего не учтёшь, и любая работающая система со временем расширяется и дополняется тем, что архитектору и в голову не могло прийти

кол-во таблиц исчисляется сотнями, а не десятками или единицами.

Согласен.

то обычный рядовой селект зохавывает четыре-пять таблиц.

Не меньше, чаще больше.

А чаще всего это селект хитрой статистики в срезе, который при проектировании и не планировался. А значит не пять таблиц а все десять, в самых хитрых комбинациях.

Для этого реализуется таблица(ы), в которую, периодически, можно по cron-у, делается этот хитрый, не предусмотренный селект, а пользовательский запрос работает уже с этой таблицей, иначе, положишь сервис пользовательскими запросами.

Вы имеете ввиду VIEW ?

Вы имеете ввиду VIEW ?

Скорее «материализованный» VIEW :) Там где они есть. Обновление по крону не всегда катит - отчёт часто должен быть оперативным на сколько это возможно. А чтобы не положить сервис запросами нужны «приоритеты» и не самое слабое железо.

Там нет ничего платного, кроме заказа сертификатов по уже пройденным задачам (это по желанию, можно и не заказывать, а просто прорешать).