Как Вы думаете при формулировке запросов SQL. Действительно ли это - опыт или понятие?
Я работал над SQL-сервером и кодированием фронтэнда и обычно сталкивался с проблемой, формулируя запросы.
Я действительно понимаю большую часть понятия sql, которые необходимы в формулировке запросов, но каждый раз, когда некоторая новая функциональность входит в изображение, которое может быть, не делают запроса SQL использования, я обычно делаю сбои, разрешающие их.
Я очень доволен запросами Select с помощью соединений и всех таких вещей, но когда дело доходит до DML операция i обычно сбои
Для каждого запроса, что я никогда делавшийся, прежде чем я обычно найду неудобным с этим при создании их. Каждый раз, когда я иду для интервью I обычно поверхности эта проблема.
Это - их некоторое понятие позади приближения при формулировке запросов SQL.
Например.
Я должен создать запрос SQL, таким образом что
A table contain single column having duplicate record. I need to remove duplicate records.
Я знаю, что могу найти решение этого запроса очень легко на поиске с помощью Google, но я хочу знать, как все приходят к желаемому результату.
Это - что-то как Practice Makes Man Perfect т.е. после того как Вы сделали это, в следующий раз, когда Вы сможете сформулировать or их некоторые logic or concept позади.
Я мог иметь, получают мой ответ решения выше проблемы просто путем регистрации его на stackoverflow, и я был бы с ответом в течение 5 - 10 минут, но я хочу знать причину. Как Вы работаете над каким-либо новым видом запроса. Действительно ли это - крупный вклад опыта или некоторых реализация понятий.
Каждый раз, когда я изучаю некоторую новую вещь в кодировании раздела I попыток использовать его везде, где я могу использовать его. Но здесь сценарий, кажется, изменяется, потому что мог бы быть, я отстаю в некоторых понятиях.
Править
Как я мог протестировать свое знание и понятия в Sql и связал запросы SQL?
9 ответов
У меня есть несколько методичный метод построения запросов в целом, и я использую его в других местах для решения любых проблем, которые мне нужно сделать.
Первым шагом ВСЕГДА является перечисление любых битов информации , которые у меня есть в запросе. Информация - это, по сути, все, что говорит мне что-то о чем-то.
Таблица содержит один столбец с повторяющейся записью. Мне нужно удалить дубликат
- У меня есть таблица (я назову ее table1)
- У меня есть столбец в таблице table1 (я назову его col1)
- У меня есть дубликатов в столбце 1 таблицы table1
- Мне нужно удалить дубликатов.
Следующим этапом построения моего запроса является определение действия , которое я возьму из имеющейся у меня информации . Я буду искать определенные ключевые слова (например, удалить, создать, редактировать, показать и т. Д.) Вместе со стандартной вставкой, обновлением, удалением, чтобы определить действие. В примере это будет УДАЛЕНИЕ из-за удаления.
Следующим шагом является изоляция .
В ответ на вопрос «действие, определенное выше, должно быть действительным только для ______ ..?» Эта часть почти всегда является самой сложной частью построения любого запроса, потому что обычно она абстрактная. В приведенном выше примере вы перечисляете «повторяющиеся записи» как часть информации, но на самом деле это абстрактное понятие чего-либо (чего-либо, где конкретное значение не является уникальным в использовании). Изоляция. также здесь я проверяю свое действие с помощью оператора SELECT. Каждый новый запрос, который я выполняю, сначала проходит через выборку!
Следующим шагом является выполнение или, по сути, часть запроса «как это сделать».
Часто на этапе изоляции вы выясняете, как это сделать, но в некоторых случаях (включая ваш), как изолировать что-то и как это исправить, - это не одно и то же. Показаны дубликаты. values отличается от удаления определенного дубликата.
Последний шаг - реализация . Именно здесь я беру все и делаю запрос ...
Подводя итог ... чтобы построить запрос, я выберу всю информацию , которая у меня есть в запросе. Используя информацию, я выясню, что мне нужно делать (действие ) и что мне нужно для этого делать ( изоляция ). Как только я знаю, что мне нужно с этим делать, я вычисляю выполнение .
Каждый раз, когда я начинаю новый «запрос», я запускаю его через эти общие шаги, чтобы получить представление о том, что я собираюсь делать на абстрактном уровне. Для конкретных реализаций фактического запроса вам необходимо иметь некоторые знания (или доступ к Google), чтобы пойти дальше этого.
Крис
Обычно, когда вам в первый раз нужно открыть защищенный от детей флакон с таблетками, вам трудно, но после этого вы готовы к тому, что может / повлечет за собой.
Так и с программированием (мне кажется).
Вы находите проблемы, исследуете передовой опыт и бьетесь головой о пару камней, но в процессе вы получите удобный набор инструментов.
Кроме того, чтение того, что пытались / делали другие, - хороший способ избежать серьезных препятствий.
В общем, с большой практикой / кодированием вы быстрее увидите шаблоны и научитесь замечать, где использовать какой инструмент.
Примеры и опыт. Вы смотрите на примеры других людей, создаете свой собственный код, и когда он начинает работать, вам больше не нужно об этом думать.
Найдите хорошую документацию к своему программному обеспечению. Я много использую Mysql, и у Mysql есть отличный сайт документации с приличной функцией поиска, поэтому вы можете получить много ответов, просто читая документы. Если вы НЕ получили ответа, по крайней мере, вы чему-то учитесь.
Затем я настраиваю базу данных в качестве примера (или использую ту, над которой работаю) и постепенно создаю свой SQL. Я склонен разделять проблему на мелкие части и решать ее шаг за шагом - это очень успешно, если вы создаете запросы, включающие много СОЕДИНЕНИЙ - лучше всего начать с какого-то конкретного случая и «заморочить» свой SQL множеством условий, например WHEN id = "123", который вы убираете, работая над решением.
Лучший и самый быстрый способ выучить хороший SQL - это работать с кем-нибудь, желательно с кем-то, кто знает больше, чем вы, но это не обязательно. Его можно заменить изучением зрелого кода, написанного другими.
Просматривая ваши ответы, у вас есть два варианта.
- Имейте копию спецификации для всего, над чем вы работаете (спецификация SQL и документация для реализации SQL (SQLite, SQL Server и т. Д.).
- Используйте Google, SO, Книги и т. Д. В качестве ресурса для найти ответы.
Вы не можете сформулировать ответ на проблему, не выполнив одно из вышеперечисленных. Первый вариант - хорошо разбираться в возможностях того, над чем вы работаете.
Второй вариант позволяет вам найти ответы, которые вы, возможно, даже не знаете, как задать вопрос. Ваш пример довольно упрощен, поэтому, если вы прочитаете документацию по спецификации / реализации, вы сразу узнаете ответ. Но бывают случаи, когда даже если вы читаете спецификацию / документацию вы не знаете ответа. Вы знаете только, что это возможно, но не знаете, как это сделать.
Помните, что для рабочих мест и руководителей важно иметь возможность решить проблему, но тем быстрее вы сможете сделайте это лучше, что часто можно сделать с помощью варианта 2.
Я думаю так же, как готовлю обед. У меня есть некоторые ингредиенты (таблицы, столбцы и т. Д.), Некоторые методы приготовления (SELECT, UPDATE, INSERT, GROUP BY и т. Д.), Затем я соединяю их так, как знаю.
Иногда я делаю что-нибудь странное, и это кажется мне ужасным на вкус или восхитительным.
Иногда я беру новые рецепты в Интернете или у друзей, а затем использую их части в своих собственных.
Я также сохраняю свои рецепты в удобных репозиториях, разбитых на многоразовые блоки.
В примере "Удалить дубликат" я бы пришел к результату, погуглив. Этот сценарий настолько редок, если БД спроектирована правильно, что я бы не стал утруждать себя хранением этой информации в голове. Зачем беспокоиться, если есть хороший ресурс, где я могу найти ее, когда она мне понадобится?
Для других запросов, действительно, практика делает совершенным.
Со временем вы запоминаете часто используемые шаблоны просто потому, что они часто используются. Редкие случаи следует держать в справочном материале. У меня просто слишком много других вещей, которые нужно помнить.
Ваш пример - это проверка того, насколько хорошо вы понимаете ключевое слово DISTINCT и предложение GROUP BY, которые являются способами работы SQL с дублирующимися данными.
Я бы посмотрел на книгу Простые смертные - я думаю, это книга Эрнандеса . Я помню, что когда я впервые серьезно занялся SQL Server 6.5, переходя от ручных баз данных ISAM и систем баз данных Access, использующих VB4, мне было трудно понять синтаксис, объединения и декларативный стиль. И SQL-запросы, хотя и мощные, были очень пугающими для понимания, потому что обычно я смотрел на сгенерированный код в Microsoft Access.
Однако, как только я разработал относительно систематический подход к последовательному и прямому построению запросов, мои навыки и уверенность быстро продвинулись вперед.