Добрый день!

Пытаюсь читать Microsoft® SQL Server® 2012. Создание запросов. Учебный курс Microsoft. (70-461)

Поясню свою проблему на двух примерах из книги.

Пример 1.

...следующий запрос группирует строки по ID грузоотправителя shipperid и году отгрузки shippedyear.

SELECT shipperid, YEAR(shippeddate) AS shippedyear,
COUNT(*) AS numorders
FROM Sales.Orders
GROUP BY shipperid, YEAR(shippeddate);

Этот запрос генерирует следующий результат:

shipperid shippedyear numorders
----------- ------------ -----------
1 2008 79
3 2008 73
1 NULL 4
3 NULL 6
1 2006 36
2 2007 143

В данном запросе shipperid и YEAR(shippeddate) сначала соединяются по OR в GROUP BY после фильтрации (обуникаливания) каждого поля. Затем происходит подсчёт COUNT(*) по каждой полученной строке.

А теперь крик души.

Вроде всё просто и понятно. Только вот до этого на 150 страницах ни слова не сказано, что перечисление GROUP BY даёт результат декартова произведения, аналога CROSS JOIN. И в таком духе выдержана практически вся книга с отсылками к ранее необъявленным (неописанным) понятиям, с призывами "обратить внимание" и "заметить". Например, при описании CTE идёт использование UNION ALL, о котором рассказывают на следующем занятии. Реально бесит.

Но в самый настоящий ступор повергла рекурсия для упомянутого CTE:


WITH EmpsCTE AS
(
SELECT empid, mgrid, firstname, lastname, 0 AS distance
FROM HR.Employees
WHERE empid = 9

UNION ALL

SELECT M.empid, M.mgrid, M.firstname, M.lastname, S.distance + 1 AS distance
FROM EmpsCTE AS S
JOIN HR.Employees AS M
ON S.mgrid = M.empid
)

SELECT empid, mgrid, firstname, lastname, distance
FROM EmpsCTE;


По логике на первом шаге должна вызваться EmpsCTE, чтобы получить данные для FROM EmpsCTE; . Первый SELECT в функции добывает данные из FROM HR.Employees. Всё нормально. И даже последующее объединение UNION ALL не вызывает вопросов.

А дальше в функции начинается жестяная жесть на основе альтернативной логЕки: данные получаются через вызов EmpsCTE:

FROM EmpsCTE AS S
JOIN HR.Employees AS M
ON S.mgrid = M.empid


который каким-то невообразимым способом обходит начальный "анкор", вызывающийся один лишь раз:

SELECT empid, mgrid, firstname, lastname, 0 AS distance
FROM HR.Employees
WHERE empid = 9

В любом нормальном и настоящем языке программирования вся эта конструкция подвисла бы наглухо до переполнения стека. Но в T-SQL всё отлично работает. Что значит лишь то, что в описании не говорят, как это работает на самом деле. Вместо этого предлагая верить , а не знать суть.

Мой вопрос: есть ли какие толковые и тонкие книжицы, разъясняющие приоритеты выполнения команд в запросах T-SQL?

Изображение нескольких графов переходов для пары десятков операторов не должно занять много места.

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

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

Поделюсь тем, что кому-то изучающему 70-461, возможно, будет полезно.

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

Попробуйте понять, что это значит:

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


А теперь сравните с оригиналом:

When you query a database for data, ultimately that data is located in tables either in that database or another database referenced by the query .


"данные либо в этой таблице, либо в другой таблице" (типа масло масляное, либо встречу динозавра, либо нет, 50 на 50, т.е. бессмыслица) против "данные в таблицах либо в этой базе данных, либо в другой базе данных"

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

tashkafox ,

Благодарю Вас за Ваше мнение.

Свою позицию формализую в нескольких пунктах:

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

2. Книга нацелена на подготовку к сдаче экзамена и потому её содержание максимально приближено к экзаменационным требованиям. Да, уверен, что в трёх-четырёх книгах сравнимого объёма можно взять ту же информацию, но и времени на их освоение потребуется в три-четыре раза больше.

3. Отдельная перетензия к переводу на русский, выражающаяся в двух проблемах. Первая - неточность перевода. Буквально убило разгадывание шарады, когда вместо оригинального "Inspect" переводчик Сержантова (судя по фамилии обязанная владеть русским) внезапно предложила сделать "Insert". Сравните сами смысловую нагрузку: "Проверьте значения" и "Вставьте значения".

Вторая проблема - использование при переводе многозначных слов русского языка. Я привык, что "view" - это view, а не какое-то "представление", "define" - это define, "constraint" - это constraint, а не непонятное "ограничение", которое в оригинале м.б. и "limitation", и "restriction" и т.д. В кодерстве значения слов обычно строго определены. Неточный перевод часто заводит читателя в лингвистическую ловушку: если с одиночным упоминанием "представления" ещё можно смириться, то смысл предложения, состоящего из нескольких строк, порой вообще невозможно понять. Особенно если оно приправлено небольшой ошибочкой по недосмотру. ;)

Поэтому читаю русский перевод одновременно держа в закладке оригинал, открытый на той же странице, который смотрю при каждом спорном случае.

4. Оригинал тоже и также можно существенно доработать (хотя понимаю, что это уже никто делать не будет). Книга всего лишь описывает структуры языка, т.е. самые базовые понятия и азы. Поэтому достаточно давать в связке ответы на три вопроса:
а) что хотите сделать?
б) как это можно сделать?
в) каковы условия и последствия выбранного решения?

Например, можно реализовать тот же PIVOT без употребления PIVOT, который по сути является макросом. Если, конечно, задаться целью овладеть материалом, а не вызубриванием предлагаемого. ;)

Автор же часто впадает в пространные абстрактные рассуждения, смысл которых до изложения кода вообще неясен. Даже если автор склонен превратить экзамен по знанию кода и его применения в экзамен по литературе или философии, ему стоило бы ознакомиться с принципами философии науки и понимать, что делать заключения и выводы можно лишь имея хотя бы два описанных в достаточной мере объекта, которые он желает посравнивать между собой. Даже не посравнивать, а привлечь неофитов, не имеющих понятия о предмете, ко сравнению. Как понимаю, автор и научный метод находятся в непересекающихся множествах. ;)

5. Учитывая всё вышесказанное, равно как и то, что на экзамене (и в последующей практике) важен именно код, считаю ключевым моментом для успешного обучения практические занятия на SSMS. Кто что там набалаболил, кто и что переврал в переводе будет неважно если обучающийся будет точно знать , как обстоят дела в реальности. Например, в качестве упражнения можно реализовать тот же PIVOT и сравнить производительность реализации с оригиналом. Это простое упражение позволит достичь понимания сути , вместо замещения его, понимания, верой в слова порой косноязычных авторитетов.

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

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

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

Закончу парой примеров того, что реально выбешивает. Глава 10, Обновление с использованием объединения (UPDATE Based on Join).

Пример 1.

Перевод:

SELECT OD.*
FROM Sales.MyCustomers AS C
INNER JOIN Sales.MyOrders AS O
ON C.custid = O.custid
Sales.MyOrderDetails AS OD
ON O.orderid = OD.orderid
WHERE C.country = N'Norway';


Оригинал:

SELECT OD.*
FROM Sales.MyCustomers AS C
INNER JOIN Sales.MyOrders AS O
ON C.custid = O.custid
INNER JOIN Sales.MyOrderDetails AS OD
ON O.orderid = OD.orderid
WHERE C.country = N'Norway';

При прочтении перевода начал думать, что есть какой-то новой неизвестный мне формат INNER JOIN, в котором можно опускать не только INNER, но и JOIN.

Пример 2. Глава 10, Занятие 2. Обновление данных.

Демонстрационные данные
Этот раздел, в котором рассматривается обновление данных, так же как и следующий, описывающий удаление данных, использует демонстрационные данные, представленные в таблицах Sales.MyCustomers с данными о клиентах, Sales.MyOrders с данными о заказах и Sales.MyOrderDetails, содержащей подробные данные о заказах. Эти таблицы являются копиями таблиц Sales.Customers,
Sales.Orders и Sales.OrderDetails из учебной базы данных TSQL2012.


При чтении главы, реально простого и примитивного материала , надо либо запускать SSMS, чтобы видеть таблицы, либо иметь под рукой их распечатку. Либо держать их в голове. Это реально утомительно ибо ресурс тратится не на восприятие материала (например "Недетерминированная инструкция UPDATE"), а на всякую отвлекающую от сути левоту.

tashkafox ,

Соглашусь с Вами в том, что практика может существенно отличаться от теории, которая зачастую не описывает все факторы, могущие влиять на процесс. Наиболее отчётливо это видно в физическом мире когда Вы пытаетесь самостоятельно воспроизвести чужой рецепт касающийся готовки пищи, сборки мебели, строительства дома, ремонта авто, шитья на машинке и т.д и т.п. Всегда что-то где-то не совпадает, оказывается неудобным для реализации или каким-то образом не оправдывает Ваших ожиданий. Точнее, не совпадает модель, созданная в Вашем мозге и практическая реализация.

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

Применительно T-SQL: если человек осознанно написал один запрос, выполняющий поставленную задачу, то он по шаблону сможет написать любой другой, решающий подобную задачу. Здесь нет никакого места для творчества и прочего "креатива". Просто тупое кодерство. Человек увидел одну причинно-следственную связь, позволяющую перевести систему из состояния А в предопределённое состояние Б. Творчество начнётся тогда, когда неописанное доселе множество переводов системы будет иметь несколько уровней вложенности и станет учитывать параллельные ветви переходов. Но об этом позже. Хотя сие следует обозначить для ясного понимания разницы между знаниями правил и построением системы на основе этих правил.

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

Теперь к сути. Практические тесты на SSMS предназначены:
а) для теста памяти обучающего (а сумел ли ты запомнить шаблон запроса? сможешь ли воспроизвети его по памяти?)
б) для положительного подкрепления, позволяющего прочно усвоить правильный шаблон (да! я вёл запрос и у меня получилось так как надо!).

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

tashkafox, это - сплошной нонсенс, когда приходится тратить кучу времени на разбор ошибок лектора или на поиск материала, описывающего структуру лекции. Ну вот как можно воспринимать текст если для понимания следующего абзаца Вас заставляют почитать дополнительную литературу? Сие есть исключительно лень автора, продиктованная незнанием или нежеланием сделать подачу материала максимально эффективной.

В силу своего опыта я знаю, чем всё обычно заканчивается. В итоге всё примитивно, просто и тупо (это ж дискретная двоичная логика, иначе и быть не может, исходники подтверждают). Да, можно философски поразмышлять над тем, чем массив отличается от списка, и даже прийти к выводу, что это - по сути одно и то же (могу наглядно показать) несмотря на то, что там пишут в книжках. Но зачем погружать студентов-неофитов в свои философствования об абстрактном? Им без того выше крыши встретится говнокода, багов и особенностей в средах разработки. Студентов, которые толком даже не знают алфавит. Зачем им усложнять освоение базы? Чтобы что? Чтобы издёргались пораньше на пустом месте, побольше стресса получили?

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

Отдельной строкой стоит упомянуть Наталью Сержантову - автора перевода с английского. В контексте инструкции MERGE читаю: "вы периодически получаете диапазон изменений". Это, $#@, что за "диапазон", $#@, такой??? Диапазон, $#@, чего ? Оказывается, речь идёт о "delta of changes", о разнице таблицы и внешнего источника. Без всяких диапазонов (range).

Наталья отдельно от автора оригинала сделала всё, чтобы заложить в обучаемом самую кривенькую из всех возможных моделей. Студенту однозначно потребуются тесты на SSMS, чтобы понять, что гон Сержантовой не имеет ничего общего с реальностью. И опять встаёт вопрос эффективности: зачем учиться так, что затем придётся переучиваться? Или, что хуже, вообще иметь некорректные знания, неверные представления, а, следовательно, несвязанный целостно и ассоциативно материал? Да, студент в итоге всё поймёт, после годовой практики, кучи багов и произведя тонны говнокода. На что потратит кучу ресурсов (ресурсов нанимателя в т.ч.). Но кто является первопричиной его ошибок? Такие вот учителя азбуке.

Для меня получение сертфиката - это всего лишь квест из разряда развлечений. Ну вот захотелось и всё тут. ;) Кто-то ходит по аттракционам ужасов, гоняет на мотике или за сутки проходит на велике по 200 км. А мне захотелось квестануть по БД. По-разному люди бодрятся.

Знаете, в чём увидел основную проблему? Нет, не в прочтении и запоминании содержания тысячи страниц (33 дня по 30 страниц). И не в практическом овладении комплексным функционалом SSMS. Для меня проблема в самом тесте. Ещё раз подчеркну - не в знаниях, не в умении их применять на практике, а в тесте этих способностей. За минуту едва ли успеваю прочесть задание. Понять его требуется ещё минута. И всё - время на ответ вышло. На размышление времени вообще не остаётся.

Подобный тест направлен на что? Правильно, на умение распознавать и воспроизводить шаблоны. Думать вообще не надо. Даже знаний может не потребоваться. ;) А уж про то, чтобы предложить и рассмотреть несколько вариантов реализации и речи нет.

Но квест есть квест. Значит, будем обучаться на дампах быстрой вычитке задачи (например, поля таблицы на полэкрана можно даже не читать - просто пропускать) и поиску по косвенным признакам верного ответа. Если MS раздаёт сертификаты за быструю реакцию, значит, её и будем тренировать. Главное ведь - это результат. :)