Посоветуйте хорошую книгу/док/ман по SQL?

зачем оно, когда моду набирает nosql?

кстати, присоединяюсь к реквесту.

что-нить по ораклу возьми.

> зачем оно, когда моду набирает nosql?
это троллинг или на полном серьёзе?

nosql это очень хороший способ убить почти любой более-менее серьёзный проект.

Введение в системы баз данных. К. Дж. Дейт

Том Кайт. Oracle для профессионалов.

хм, а почему? Разработчики той же MongoDB говорят, что это хорошо масштабируемая быстрая СУБД.

ну да. можно oracle sql или oracle pl/sql. второе даже интересней, потому что будет более понятно до куда остальные базы могут когда-нибудь дойти.

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

вот есть у меня, например, проект который я веду - ERP-система, порядка 300 таблиц для начала, некоторые с 50-100 полями, и тд и тп.и бывают, бывают поиски по несколько неожиданным полям. типа «вывести все заявки покупателей европы которые были частично оплачены и в заявках присутствовала микросхема MAX323» (при том что заявка это не одна строка а много, бывает под 100 строк одна заявка покупателя), и что народ платит как «1000 долларов за счета 3232,3233» так и «частичная оплата 500 долларов по счету 3232» и даже «предоплата без счета за оказание будущих услуг».
и когда в базе данных МНОГО таких заявок, ты не будешь (поверь мне) выбирать все это в память и потом обсасывать это питоном/перлом/пыхом. потому что памяти не хватит.

ну как я понял, основное назначение noSQL - как раз сделать так, чтобы таблиц было не 300, а 30. И, вроде как, можно использовать хоть регекспы в запросах (судя по мануалу mongoDB).

> nosql это очень хороший способ убить почти любой более-менее серьёзный проект.

Ой, так сложно не сбрасывать данные в кучу, а укладывать их сразу в требуемые структуры/последовательности? Не, можно конечно эту работу доверить SQL, пусть само разбирается где и чего лежит и как это скомпоновать, только потом не надо говорить «ой, в любом подобном проекте база - основной источник нагрузки»

А как ты в них искать будешь? Любой поиск это либо «поиск перебором» либо «поиск по индексу», ничего нового к тому моменту как я уехал в отпуск неделю назад придумано не было.

А чем поиск в noSQL отличается от поиска в Orace?

А насчет количества таблиц я немного ошибся, судя по этой http://habrahabr.ru/blogs/nosql/86429/ статье, их наоборот многовато становится.

Mastering SQL

на самом деле их может стать как меньше так и больше.
кстати как и оракле/постгресе.
ты можешь хранить в ячейке таблицу. и тогда запросы будут такие же.
но оптимизация в случае sql все-таки будет получше.

а так, mongodb просто в идеальном варианте вырождается в обычную субд, запросы к которой пишутся на javascript вместо sql.

> Mastering SQL

тоже на английском.
(если брать английские тексты, то круче Целки зверя нет, но нада русские).

> но оптимизация в случае sql все-таки будет получше.

если большую часть времени используется ORM, то уже не так очевидно...

>а так, mongodb просто в идеальном варианте вырождается в обычную субд, запросы к которой пишутся на javascript вместо sql.

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

ффф вот это как раз и есть камень преткновения. у меня есть большое желание начать засовывать логику в базу. то есть писать функции, методы и тд внутри базы.

могу порекомендовать книгу мартина грабера «понимание sql» http://sql.ru/docs/sql/u_sql/index.shtml, потом лично для меня крайне полезным оказался задачник сергея моисеенко «sql задачи и решения». боюсь, что обе этих книги теперь можно раздобыть только в электронном виде.

как работать с OLAP-кубами , юзая NoSQL ? если никак, тогда в топку.

я специально прям щас прорыл документацию mongo а потом даже обратился к гуглу с вопросом «mongodb join». ответ такой (с самого сайта монго):
«But MongoDB does not support joins and so....»
на этом моменте можно закапывать.

Объясняю почему. У меня, например, есть таблицы «производитель детальки», «деталька» (с foreign key на производителя), «строка запроса покупателя», «запрос покупателя», «покупатель», «статус строки запроса (с описанием на рус/анго/немец)», «статус запроса (с описанием на рус/анго/немец)» и так далее.
и их как-то разумеется надо все джоинить. причем, если «статусы» это порядка 10 строк, то «произвоидитель» - 6000, а «деталька» - 100000, «строка запроса» или «предложение поставщика» - МНОГО.
так что хрен ты в памяти будешь этим оперировать.
особенно когда нужно выбрать отдалённое пересечение двух таблиц, например «пользователь, статус и производитель» - у меня это порядка 20 таблиц внутри запроса.
можно конечно «схлопнуть» денормализацией это, но будет сплошной капец - во-первых катастрофически увеличится размер базы на харде, во-вторых сам знаешь к чему приведет денормализация.

ну да, в этом случае для использования mongo нужна либо денормализация, либо переосмысливание архитектуры базы. Хотя согласен, памяти/места будет потреблять больше в любом случае, чем SQL. Хотя, может, какие-нибудь костыли и есть для обхода.

Спасибо! Вот это ценно.

самое забавное, 1мегабайт против 3мегабайт - абсолютно не важно. а вот 100гигабайт против 1террабайта - очень важно. потому в память не влезет и из-за задержек при работе с диском и тд.

Есть в переводе от bhv. Просто не помню, как в русском называется

> потому в память не влезет и из-за задержек при работе с диском и тд.

подумать как распаралеллить на несколько серверов?

а смысл если в sql параллелить не надо а в mongodb надо? то есть «мужественно решать задачи которые сам себе поставил»?

>Хотя согласен, памяти/места будет потреблять больше в любом случае, чем SQL.

«But MongoDB does not support joins and so....»

джойны не поддерживает, памяти и места жрёт больше, про работу с OLAP-кубами забыть, плюс отказаться от старого доброго, крайне удобного и хорошо изученного SQL в пользу х.з. чего... а может, в печку его, этот NoSQL, а ?

> а может, в печку его, этот NoSQL, а ?
блин, капитан очевидность...

Дейт «Введение в системы управлениями баз данных»

>а может, в печку его, этот NoSQL, а?
В печку надо не его, а школьников, которые задачи решают неправильно выбирая инструменты, отбрасывая классику только из-за того, что что-то другое стало «модным» :)

http://free-books.dontexist.com/search?req=SQL&nametype=orig

Выбирай на любой вкус, русскоязычные будут ближе к концу

> А как ты в них искать будешь? Любой поиск это либо «поиск перебором» либо «поиск по индексу», ничего нового к тому моменту как я уехал в отпуск неделю назад придумано не было.

хеширование + различные деревья, оптимизированные под конкретные запросы, возможно десяток деревьев, причем самое приятное то, что наполнение оных ты можешь контролировать самостоятельно с филигранной точностью

> как работать с OLAP-кубами , юзая NoSQL ? если никак, тогда в топку.

Всосать все в оперативку, там же и процессить вдоль и поперек.

а если OLAP размером в пол-террабайта (это реальная задача, кстати)?

У оракла неплохой справочник по SQL. Вот ссылка на quick reference, там есть и полный.

http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14195%2Ftoc.htm&remark=portal+%28Books%29

Остается только виртуальная память, увы.

Он не объясняет ничего кроме синтаксиса. Паттерны, алгоритмы, анализ - ничего нет.

Кроме Дейта, еще неплохо «Understanding SQL» by Martin Gruber - «Понимание SQL», в русском переводе можно взять, например здесь

Лично я кроме «Теория и практика построения баз данных» Кренке, 9-е издание, ничего не читал. Остальное решается на практике, я вообще не понимаю, зачем существуют книжки из серии «набор операторов в языке xyz» или там «язык xyz recipes».

я согласен с тем, что личная практика в изучении SQL - очень правильное дело, но необходимо также рассмотреть чужие сложные примеры до того, как их аналоги придётся заюзать самому - потому что простота SQL обманчива. иначе во время решения реальной задачи голова может заболеть очень сильно. вот задачник сергея моисеенко «sql задачи и решения» мне очень капитально в своё время помог с рассмотрением сложных примеров. хотел бы найти ещё парочку таких задачников, хотя в принципе можно порыть sql.ru и сделать оттуда типа конспект.

вспомнил ещё одну книжицу. сразу говорю, что прочитал только первую главу, да и то вскользь, там всё строится на примерах, но много «воды».можно найти полезные паттерны и алгоритмы . итак, Михаил Фленов «Transact-SQL». конкретные примеры заточены под MS SQL Server, но большинство можно без особого напряга экстаполировать на другие СУБД.

Да я вообще не вижу смысла в изучении «сложных примеров» заранее - особенно сейчас, во времена гугла, когда решение любой сложной задачи доступно за 5 секунд. Что мне, один из 100 выученных примеров когда-то пригодиться?

Разве что для тренировки? Но для тренировки лично мне достаточно просто работать над проектами - обучение проходит быстрее и без отрыва от производства (а не с отрывом от семьи).

Как в музыке - кто-то считает, что нужно учить гаммы, а кто-то - что гаммы есть в любом упражнении, поэтому лучше сразу учить упражнения. Не так скучно.

В общем, я предпочитаю теоретические книги типа Domain Driven Design, CLR via C#, Peopleware, Modern C++ Design, Code Complete, и т.п. Вещи типа вебкастов, демонстрирующих процесс написания блога и в какие окошки тыкать, вообще за гранью моего понимания.

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

> часто встречающихся задач

Решения часто встречающихся задач и так изучаются не отходя от кассы, ибо по-определению
1. Они тебе встретятся сразу.
2. Решения для них в изобилии есть в гугле, ибо и другим они встречаются часто.
Смысл ради них читать книги?

углублённое понимание

Ну вот для этого я и читаю вышеуказанные теоретические книги, ибо они дают углубленное понимание. А книги с примерами... возьмём, скажем, (More) Effective C++ Мейерса (если я правильно помню, именно там так всё было, как я описываю):
- примеры надуманные - да, ситуации _могут_ встретиться в жизни, и эту книгу стоит почитать, если вы автор boost-а; обычным кодерам она ни к чему;
- вероятность встретить что-то подобное в реальных проектах мала по сравнению с временем чтения/объяснения каждого примера;
- стиль написания примеров традиционно идиотский: class A { B b; } - автор даже не утруждает себя придумыванием реальных случаев и, соответственно, имён переменных - это всё равно, что читать обфускированный код;
- соответственно, проще и быстрее будет изучить это на реальной практике.

свой уровень можно неплохо поднять, периодически роясь в чужих исходниках

Свой уровень можно поднять, периодически участвуя в реальных проектах. Всё остальное может только облегчить этот процесс.

1.Идешь сюда
http://www.sql.ru/books/books.aspx?g=6&s=0
http://www.sql.ru/books/books.aspx?g=7&s=0
...........
2. ПРОФИТ!

а почему? Разработчики той же MongoDB говорят, что это хорошо масштабируемая быстрая СУБД

А потому что у них нет ACID, Consistency
То есть они не гарантируют что изменения которые пользователь сделал попадут в БД. Т.е. ты нажал «перевести деньги с PayPal», NoSQL с твоей карты их списала, а по адресу заслать не успела, очередь сообщений на сервере упала, а она не обязана за этим следить.

«Если пользователю очень надо он еще раз нажмет Submit» На этом и основана «масштабируемость» NoSQL

да, посмотрел - действительно, mongoDB даже транзакции не поддерживает. Тогда однозначно втопку для серьёзных проектов.

High-Performance Parallel Database Processing and Grid Databases 9780470107621

The sizes of databases have seen exponential growth in the past, and such growth
is expected to accelerate in the future, with the steady drop in storage cost accom-
panied by a rapid increase in storage capacity.Many years ago, a terabyte database
was considered to be large, but nowadays they are sometimes regarded as small,
and the daily volumes of data being added to some databases are measured in
terabytes. In the future, petabyte and exabyte databases will be common.
With such volumes of data, it is evident that the sequential processing paradigm
will be unable to cope; for example, even assuming a data rate of 1 terabyte per
second, reading through a petabyte database will take over 10 days. To effectively
manage such volumes of data, it is necessary to allocate multiple resources to it,
very often massively so. The processing of databases of such astronomical propor-
tions requires an understanding of how high-performance systems and parallelism
work