Как думать в SQL?

Question

Как мне перестать думать о каждом запросе с точки зрения курсоров, процедур и функций и начать использовать SQL, как и должно быть? Делаем ли мы переход к мышлению в SQL просто на практике или есть какое-то волшебство в изучении языка запросов на основе множеств? Что вы сделали, чтобы совершить переход?

Answer 1

Несколько примеров того, что должно прийти вам в голову, если вы настоящий SQL Компьютерщик:

• Библейское согласие является FULLTEXT указателем на Bible

• Luca Pacioli s Summa de arithmetica , который описывает бухгалтерию с двумя записями, фактически является нормализованной схемой базы данных

• Когда Xerxes I сосчитал свою армию, ограждая область, занятую 10,000 его людей, а затем маршируя через эту воронку, он использовал метод HASH AGGREGATE.

• The House That Jack Built следует переписать с помощью самостоятельного соединения.

• The Twelve Days of Christmas следует переписать с помощью самостоятельного соединения, а ROWNUM

• There Was An Old Woman Who Swallowed a Fly следует переписать, используя CTE '*

• Если бы European Union называли European Union All, мы бы увидели 27 написания для слова euro на банкноте евро вместо 2.

И, наконец, вы можете прочитать в моем блоге плохую статью о том, как I перестал беспокоиться и научился любить SQL (я почти забыл, что написал):

• Нажмите

И еще одна статья только на эту тему:

• Двойственное мышление в SQL

Answer 2

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

Answer 3

Главное, что вы манипулируете множествами и элементами множеств; и связывание различных наборов (и соответствующих элементов) вместе. Это действительно суть, имхо. Вот почему каждая таблица должна иметь первичный ключ; почему вы видите операторы set на языке; и почему операторы set, такие как UNION, не будут (по умолчанию) возвращать повторяющиеся строки.

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

Answer 4

Мышление Джо Селко в наборах (книга)

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

Эта книга изменит способ, которым вы подумайте о проблемах, которые вы решаете с программами SQL .. Сосредоточение на трех ключевые методы на основе таблиц, Celko раскрывает свою силу через подробные примеры и понятные объяснения. Как Вы овладеете этими техниками, вы будете найти, что вы можете осмыслять проблемы, как корни в наборах и разрешимый через декларативный программирование. Вскоре вы будете писать быстрее, писать больше эффективный код и применение полного сила SQL.

Answer 5

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

«Дайте мне имена и зарплаты сотрудников в отделениях, расположенных в Лондоне»

Соответствующий SQL почти натуральный:

select name, salary
from employees
join departments on departments.deptno = employees.deptno
where departments.location = 'London';

Мы "сказали" SQL, как объединять отделы с сотрудниками, но только декларативно (NATURAL JOIN устраняет необходимость делать это, но опасно, поэтому не используется на практике). Мы не определили процедурно как это должно быть сделано (например, "для каждого отдела найти всех сотрудников ...") SQL может свободно выбирать оптимальный метод для выполнения запроса.

Answer 6

Одно упражнение, которое вы можете попробовать, это:

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

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

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

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

Несколько вещей, на которые стоит обратить внимание:

• Рекурсия и графики - довольно продвинутые техники; Вы можете начать с чего-то проще. (У Джо Селко хорошая книга на эту тему, если вам интересно.)
• Часто существует большая разница между BIT и C-style bool. По крайней мере, вам, возможно, придется явно привести ваш вывод с INT к BIT.
• OUTER JOIN s полезны, когда часть данных может быть пустой, но старайтесь не злоупотреблять ими.

Answer 7

Когда люди спрашивают меня об объединениях, я отправляю их здесь , они имеют отличное визуальное представление о том, что они есть!

Answer 8

Я обнаружил, что Art Of SQL был полезен для правильного мышления.

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

Вы пишете невероятно сложное заявление об обновлении, которое может быть трудно понять кому-либо, кроме вас, и трудно поддерживать, или вы пишете менее эффективную, но более простую в управлении процедуру?

Я НАСТОЯТЕЛЬНО рекомендую, чтобы вы помнили, что в операторах SQL могут быть комментарии, поясняющие, что они делают, а не просто хранимые процедуры.

ссылка: Искусство SQL

Answer 9

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

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

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

Другим хорошим способом было бы прочитать книгу по теоретическим / математическим основам для РСУБД. Они имеют дело только с теорией множеств и с тем, как части синтаксиса SQL-запросов напрямую связаны с математикой. Конечно, это требует, чтобы вы любили математику. :)

Answer 10

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

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

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

Вы можете сделать это (и многое другое) в одном операторе SQL, просто научитесь. Это очень выгодно.