Разработчик sql что делает

В должностные обязанности программиста MS SQL входит:
— создание и оптимизация запросов SQL/T-SQL (хранимых процедур, триггеров, функций, представлений);
— создание и оптимизация отчетов;
— анализ требований заказчика и разработка/доработка соответствующих объектов баз данных;
— участие в разработке архитектуры данных и структур баз данных;
— разработка объектов базы;
— администрирование баз данных;
— анализ производительности баз данных‚ оптимизация и ускорение обработки запросов;
— разработка и поддержание в актуальном состоянии документации по своему направлению деятельности.

Заработная плата и требования работодателей
Средняя заработная плата программиста MS SQL в Москве составляет в Санкт-Петербурге — в Волгограде — в Воронеже — в Екатеринбурге — в Казани — в Красноярске — в Нижнем Новгороде — в Новосибирске — в Омске — в Ростове-на-Дону — в Самаре — в Уфе — в Челябинске —

От начинающих программистов MS SQL требуют наличия технического высшего образования (возможно, неполного), понимания реляционной модели данных, знания классических алгоритмов и структур данных, уверенных знаний одного из процедурных языков (PL/SQL,T-SQL, SQL PL), опыта написания скриптов и хранимых процедур на языке запросов, а также знания английского языка на уровне чтения технической документации. Зарплатные предложения для специалистов без опыта работы на данной позиции в Москве начинаются , в Санкт-Петербурге —

От специалистов, имеющих опыт работы программистом MS SQL от года, работодатели ждут знания архитектуры MS SQL и способов оптимизации производительности, понимания принципов работы баз данных (уровней изоляции‚ блокировки данных‚ плана выполнения запроса и пр.), знания средств обеспечения стабильности функционирования БД (технологии репликации, кластеризации, резервного копирования и восстановления) и целостности данных, а также умения разбираться в чужом коде. Дополнительными преимуществами будут знание XML, XSLT и методик организации процесса разработки в команде (Scrum, Kanban, Waterfall). Зарплатные предложения для соискателей, соответствующих указанным требованиям, составляют в Москве, в городе на Неве.

Специалисты, имеющие уверенный опыт разработки архитектуры базы данных, оптимизации сложных запросов и работы с высоконагруженными базами данных, могут претендовать на более высокие зарплаты. От кандидатов требуют знания дополнительных инструментов работы — SQL Management Studio, SQL Server Profiler, SQL Reporting Services, SQL Server Integration Services, SQL Server Analysis Services. В некоторых случаях может понадобиться знание одного или нескольких языков программирования (С++, C#, Python, PHP и др.) и навыки работы с другими базами данных (Oracle, MS Dynamics и т.д.). Минимальный опыт работы с MS SQL — 3 года. Зарплатные предложения в этом диапазоне в Москве достигают , в Северной столице —

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

Регион Диапазон I Диапазон II Диапазон III Диапазон IV Медиана
(без опыта работы программистом MS SQL) (с опытом работы года) (с опытом работы лет) (с опытом работы лет) (средняя заработная плата)
Москва 90 000
Санкт-Петербург 75 000
Волгоград 48 000
Воронеж 50 000
Екатеринбург 61 000
Казань 50 000
Красноярск 56 000
Нижний Новгород 53 000
Новосибирск 59 000
Омск 48 000
Пермь 54 000
Ростов-на-Дону 30 000 — 36 000 36 000 — 44 000 44 000 — 60 000 60 000 — 110 000 54 000
Самара 30 000 — 36 000 36 000 — 43 000 43 000 — 60 000 60 000 — 110 000 54 000
Уфа 28 000 — 33 000 33 000 — 40 000 40 000 — 55 000 55 000 — 100 000 50 000
Челябинск 30 000 — 35 000 35 000 — 42 000 42 000 — 62 000 62 000 — 105 000 53 000
Читайте также  Прошивка для gt s5300

81% кандидатов на позицию программиста MS SQL — мужчины. 93% соискателей имеют высшее образование. 10% претендентов владеют английским языком на свободном или разговорном уровне.


Ознакомиться с зарплатным индексом Superjob в сегменте «Информационные технологии»

2 года опыта работы SQL(PL/SQL) разработчиком. Сейчас активно копаю в сторону PostgreSQL, благо, во многом схож с Oracle. Так вот мне интересно, что должен знать SQL разработчик с перспективой захода в Администрирование и ETL(Data Warehouse и т.п.). На данный момент работаю Junior PHP/JS разработчиком(надеюсь я выстою на этой позиции и буду развиваться), но все же не хочется отходить от БД и SQL.
Плюсом к моему бэкграунду, есть некоторое знание Python(на junior’a конечно не потяну, но хоть что-то). Хотелось бы услышать комментарии тех, кто связан с SQL разработкой. Спасибо что прочли вопрос)

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

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

6. «WITH (NOLOCK)» не означает, что блокировок не будет вообще

На одном из этапов своей карьеры разработчика вы можете начать использовать хинт WITH (NOLOCK) повсеместно, поскольку с ним ваши запросы выполняются быстрее. Это не всегда плохо, но может сопровождаться неожиданными побочными эффектами, про которые Kendra Little рассказывала вот в этом видео. Я же сфокусируюсь только на одном из них.

Когда ваш запрос обращается к какой-либо таблице, даже с хинтом NOLOCK, вы накладываете блокировку стабилизации схемы (schema stability lock, Sch-S). Никто не сможет изменить эту таблицу или её индексы до тех пор, пока ваш запрос не завершится. Это не кажется серьёзной проблемой до тех пор, пока вам не понадобится удалить индекс, но вы не сможете этого сделать, поскольку люди постоянно работают с этой таблицей, находясь в полной уверенности, что не создают никаких проблем, поскольку они используют хинт WITH (NOLOCK).

Читайте также  Процессор amd e2 9000 1800 мгц

Здесь нет «серебряной пули», но начните читать об уровнях изоляции SQL Server — я полагаю, что уровень изоляции READ COMMITTED SNAPSHOT будет наилучшим выбором для вашего приложения. Вы будете получать целостные данные с меньшим количеством проблем с блокировками.

5. Используйте три строки соединения в своём приложении

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

  1. Строка соединения для записи и чтения «в реальном времени» — это та строка соединения, которую вы используете сейчас и думаете, что все данные должны приходить именно отсюда. Вы можете оставить весь свой код таким, какой он есть сейчас, но когда будете что-то дописывать, или изменять текущий, подумайте о том, чтобы изменить в запросах строку соединения на одну из представленных ниже.
  2. Строка соединения для получения «относительно свежих» данных, возрастом 5-15 минут – для данных которые могут быть слегка устаревшими, но всё равно сегодняшними.
  3. Строка соединения для «вчерашних» данных – для отчётов и построения трендов. Например, в онлайн-магазине, с этой строкой соединения вы можете вытягивать пользовательские обзоры к товарам, а самих пользователей предупреждать, что их обзоры будут опубликованы на следующий день.

Первую строку соединения «масштабировать» достаточно сложно, в SQL Server не очень-то много вариантов для «масштабирования операций записи» (такие варианты есть, но их очень тяжело применять и управлять ими). Вторую и третью строки соединения «масштабировать» значительно легче и дешевле. Чтобы получить больше информации об использовании разных строк соединения, вы можете прочитать вот этот мой пост.

4. Используйте промежуточную БД

Вероятно, вы используете БД для выполнения каких-то второстепенных задач – вычисления, сортировка, загрузка и т.д. Если вдруг эти данные пропадут, вы вряд ли сильно расстроитесь, но вот структура таблиц – это, конечно, другое дело. Сейчас вы делаете всё в «основной базе данных» вашего приложения.

Создайте отдельную базу данных, назовите её MyAppTemp, и делайте всё в ней! Поставьте ей простую модель восстановления и просто создавайте резервную копию раз в день. Не заморачивайтесь с высокой доступностью или аварийным восстановлением этой БД.

Использование такой техники имеет кучу плюсов. Она минимизирует количество изменений в основной БД, а значит резервные копии журнала транзакций и дифференциальные бэкапы будут делаться быстрее. Если вы используете log shipping, по-настоящему важные данные будут копироваться быстрее. Вы даже можете хранить эту БД отдельно от других баз, например на недорогом, но шустром SSD-диске, оставив основную систему хранения данных для критически важных в продакшене данных.

3. «Вчерашние» статьи и книги могут перестать быть актуальными сегодня.

SQL Server вышел уже больше десяти лет назад и за эти годы в нём произошло множество изменений. К сожалению, старые материалы не всегда обновляются, чтобы описать «сегодняшние» изменения. Даже свежие материалы из проверенных источников могут быть неправильными – вот, например, критика методики Microsoft по повышению производительности SQL Server. Microsoft Certified Master Jonathan Kehayias нашёл множество по-настоящему плохих советов в документе Microsoft.

Читайте также  Сколько людей с отрицательным резус фактором

Когда вы слышите что-то, что звучит как хороший совет, я предлагаю вам использовать стратегию, обратную стратегии доктора Фила. Доктор Фил говорит, что вы должны «проникнуться» любой идеей на протяжении 15 минут. Вместо этого, попробуйте возненавидеть её – постарайтесь опровергнуть то, что вы прочитали перед тем как применять это в продакшене. Даже если совет чертовски хорош, он может быть не очень-то и полезным на вашей системе. (Да, это относится и к моим советам).

2. Избегайте использования ORDER BY; сортируйте данные в приложении

На сортировку результатов вашего запроса, SQL Server тратит процессорное время. SQL Server Enterprise Edition стоит порядка 7000$ за одно ядро – не за процессор, а за само ядро. Двухсокетный, шестиядерный сервер обойдётся примерно в 84000$ — и это только цена лицензий, не считая железа. Вы можете купить чертовски много серверов приложений (даже с 256 ГБ оперативки на каждом) за $84k.

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

UPD. Я получил множество комментариев о том, что приложение нуждается, например, только в десяти строках, вместо десяти миллионов строк, возвращаемых запросом. Да, конечно, если вы пишете TOP 10, вам нужна сортировка, но как на счёт того, чтобы переписать запрос так, чтобы он не возвращал кучу ненужных данных? Если же данных так много, что серверу приложений приходится тратить слишком много ресурсов на сортировку – так ведь и SQL Server выполняет ту же самую работу. Мы поговорим о том как находить такие запросы на вебинаре, ссылка на который есть в конце поста. Кроме того, помните, что я сказал «Избегайте использования ORDER BY», а не «Никогда не используйте ORDER BY». Я точно так же использую эту инструкцию – но, если я могу избежать этого на очень дорогом уровне баз данных, я стараюсь это сделать. Вот что означает «избегать».

(А это часть, в которой фанаты MySQL и PostgreSQL рассказывают о том как снизить стоимость лицензий, используя СУБД с открытым исходным кодом). (А в этой части вы ждёте, что я им остроумно отвечу, но я не буду этого делать. Если вы разрабатываете новое приложение и задумались о выборе БД, прочтите мой ответ на StackOverflow о том какая БД выдержит наибольшую нагрузку.)

1. У SQL Server есть встроенные инструменты для поиска узких мест, не влияющие на производительность

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

  • какие запросы генерируют наибольшую нагрузку на вашем сервере
  • какие индексы просто занимают место и замедляют операции вставки/удаления/обновления
  • какие узкие места есть на вашем сервере (CPU, диск, сеть, блокировки и т.д.)?

Всё что вам нужно знать – это где всё это посмотреть — и во вторник, пятого марта, мы вам это покажем. Мы делаем 30-минутный вебкаст для подготовки разработчиков и вы можете зарегистрироваться на него здесь (upd вебинар успешно прошёл, запись можно посмотреть здесь).

Примечание переводчика: любые предложения и замечания по переводу и стилистике, как обычно, приветствуются.

Ссылка на основную публикацию
Adblock
detector