Каждый оператор SQL должен быть проверен администратором базы данных - часто?

11

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

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

Ишвара
источник
2
Ну, мы не помещаем операторы SQL в код. Тем не менее, ВСЕ код должен быть рассмотрен соответствующими знающими людьми.
CaffGeek
4
Веб-разработка имеет решающее значение. Результатом является непосредственное обращение к клиенту (который является вашим королем), и чаще всего конфиденциальные данные доступны для веб-сервера.
Титон
2
Вопрос в том, если не каждый запрос передается администратором базы данных, как вы определяете, что должен и не должен передавать администратор базы данных?
программист
6
@thiton: Это общее утверждение, предполагающее, что ВСЕ веб-приложения общедоступны и являются наиболее важными приложениями в организации. Это просто неправда. Иногда веб-приложения третьего уровня или ниже (по сравнению с другими приложениями). Некоторые из них используются только небольшими внутренними командами. Не зная, над чем работает @ DanEllis, мы действительно не знаем, насколько важна эта работа по веб-разработке.
FrustratedWithFormsDesigner
2
Вы еще не укушены? Подумайте о том, почему эта процедура применяется ...

Ответы:

15

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

В целом мы искали:

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

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

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

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

bwalk2895
источник
-1 Отличный ответ, но, к сожалению, вопрос был о проверке БД после обзора коллег-программиста. Этот ответ действительно отвечает на вопрос «следует ли пересмотреть весь код», но этот вопрос не задавался. Я не одобряю много или злобно, только когда они отвечают, это не ответ на вопрос.
Майкл Даррант
Точно. Это код, который уже был рассмотрен в контексте . Это важно Запрос в отдельности может выглядеть безобидным, но поместите его в цикл, и внезапно это станет не так.
Ишвара
1
Есть ли инструменты для автоматизации такого рода вещей? Я имею в виду инструмент, который создает план выполнения для всех отправленных запросов, а затем помечает что-либо при полном сканировании таблицы или декартовом продукте. Я сомневаюсь, что он мог бы поймать все , но это, вероятно, ускорило бы время проверки, а также могло бы быть выполнено разработчиками через скрипт, или даже лучше, если бы оно запускалось автоматически во время регистрации кода.
FrustratedWithFormsDesigner
10

Это полностью зависит от окружающей среды, отрасли и компании.

Несколько примеров:

  • В НАСА несколько уровней проверки и рецензирования являются стандартными. Наиболее известная «двойная проверка» должна была быть, когда зонд был отправлен на Марс, а США делали вычисления в футах, а европейцы - в метрах. Зонд был потерян.

  • При запуске без администратора баз данных (обычно в наши дни) не будет обзора администраторов баз данных и, возможно, даже не будет обзора программистов (например, если в компании нет других программистов).

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

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

Майкл Даррант
источник
5

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

  • Сколько времени тратит разработчик на извлечение sql из кода и подготовку его к отправке в администратор БД
  • Сколько времени занимает администратор базы данных, чтобы просмотреть sql?
  • Как часто изменения запрашиваются администратором базы данных? Разбить по
    типу запроса ?

Отслеживание этого в течение некоторого времени, вероятно, покажет, насколько он важен и насколько он эффективен.

BZink
источник
6
Это отличные вещи для измерения. Сколько времени у вас уходит на исправление неработающего кода, который был допущен в производство? Сколько часов занимает отдел продаж и маркетинга, чтобы найти клиентов для замены этих потерянных клиентов, в то время как ваш сайт не работал, потому что пропущенное предложение WHERE вызвало повторное сканирование таблицы? Проверка кода имеет свои издержки и выгоды, не пренебрегайте также.
4
Вот почему важно знать, сколько раз администратор запрашивает / запрашивает изменения. Вопрос прямо говорит о том, что все проверяется, без исключений. Это такая широкая политика, которая обычно имеет больше затрат, чем выгод. Я большой сторонник проверки и тестирования кода, но это не значит, что каждая строка проверяется или проверяется. Мы должны быть профессионалами, и есть разница между контролем качества и присмотром за детьми.
BZink
4

Большинство разработчиков совершенно невежественны в отношении баз данных. Они даже не осознают своего невежества. Раньше я сам был невежественным разработчиком.

Разработчики живут в мире оптимизации-зла. Это мышление не работает, когда вы выполняете операции с диском. Это мышление не работает, когда вы выбираете тип данных, который в 8 раз больше, чем должен быть, в результате чего индекс будет в 8 раз больше, чем должен быть, чтобы он больше не мог поместиться в памяти. Это мышление не работает, когда вы программируете против универсального API, который избыточно обновляет все столбцы в таблице (нет, спасибо бобам Java).

Они не знают, что такое полное сканирование таблицы. Они не знают, как обрабатывать данные в одной операции набора вместо открытия курсора. Хуже, чем курсор, они будут запрашивать данные, а затем построчно обрабатывать их, возвращаясь назад и вперед в базу данных, когда будет достаточно одного простого обновления на языке «джейн». В результате УЖАСНЫЕ представления.

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

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

FormerIgnorantDeveloper
источник
Хотел бы ты звучать более святым, чем ты?
Seseseacat
2
@Karpie, по крайней мере, он потратил время, чтобы ответить, опираясь на свой собственный опыт, вместо того, чтобы делать бесполезный, саркастический комментарий к чьему-либо ответу, как это сделал Карпи.
Дрю
2

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

TMN
источник
2

Я не работал в такой среде, как и я.

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

Если я не достаточно компетентен для простых SELECTзапросов, меня должны уволить.

Натан Лонг
источник
1
Хотя это разумная точка зрения, вы должны допустить, что мы очень немногие из нас, настолько же умны, как нам хотелось бы думать, и худшие правонарушители - самые невежественные (почти по определению, а не те, кто рядом), так как вы избегаете проблема в том, чтобы иметь общее правило - все относятся одинаково
Murph
2
@ Murph - абсолютно. Я мог ошибиться. Но я также мог делать 2-часовые перерывы в ванной каждый день. Должны ли все следить за временем в ванной, чтобы предотвратить это? Должны ли мы подписывать формы, чтобы получить скрепки, чтобы избежать кражи скрепки? В какой-то момент вы должны либо доверять людям, либо увольнять их. Мой медленный запрос имеет свою цену, но зато отнимает много времени и усилий. Только если небольшие различия в производительности базы данных будут стоить миллионы (или жизней), я бы согласился на подобные вещи.
Натан Лонг
1
Проблема в том, что вы, вероятно, не средний разработчик; и, скорее всего, не проблема разработчика. Я работал в таком месте, как это, и это было довольно отстойно; но вы знаете, что? Наши администраторы базировались в середине ночи, когда запросы прерывались, а не я. Если они несут ответственность, они имеют право пересмотреть код, за который они несут ответственность.
Теластин
@Telastyn - «не средний разработчик», которого я не покупаю; Я все еще говорю, не нанимайте плохих разработчиков. Но да, если администраторы должны получить вызов, я сочувствую немного больше.
Натан Лонг
@NathanLong касается контекста - в контексте, в котором вы работаете, это, по-видимому, не проблема, в других, очевидно, у него есть потенциал, и один из способов избежать определенных проблем - это иметь то, что может казаться бессмысленными правилами (хотя , как тот факт, что я всегда использую {} в моих утверждениях if, это сделано для определенной цели). Это плохо «потому что мне это не нравится, и я думаю, что я в безопасности, поэтому это не должно относиться ко мне» - сомнительный аргумент (та же логика применяется для игнорирования ограничений скорости). Хм, это аргументированный) -: К сожалению.
Мерф
2

Я видел это сделано в нескольких разных местах. Это здорово в теории, но я редко видел, чтобы это было эффективно. Вот почему Во-первых, если у вас есть команда администраторов баз данных (или других людей), я, как правило, обнаружил, что наименее компетентный или наименее любимый человек из группы получает основную работу по проверке. Почему ты говоришь? Это потому, что никто больше не хочет этого делать, а все остальные заняты тем, что, возможно, более неотложно. Когда-либо видел, чтобы администратор баз данных сидел без дела и говорил: «Чувак, все работает отлично; я могу просто сидеть сложа руки и бродить по сети. Хотелось бы мне что-нибудь сделать». Я тоже, по крайней мере, не хорошие. Они так же заняты или заняты, как и все остальные. Это означает, что человек, который является наименее способным, скорее всего, делает обзор, и это именно тот человек, которого вы не хотите делать. Код, который вы хотите просмотреть, - это действительно очень сложный код, на который люди смотрят и выдают его за некое подобие черной магии. Младшие администраторы или просто плохие администраторы никогда не смогут уловить тонкости того, как работает действительно сложный запрос. Редко, как никогда, кто-то когда-либо говорит: «Человек, которого я не думал выбрать одну строку из таблицы, используя первичный ключ! Спасибо DBA, ты спасатель». Таким образом, в этом сценарии действительно все, что вы делаете, - это создаете много работы за небольшую ценность. Не думайте о выборе одной строки из таблицы, используя первичный ключ! Спасибо администратору базы данных, что вы спасатель ». Так что в этом сценарии действительно все, что вы делаете, - это создаете много работы за небольшую ценность. Не думайте о выборе одной строки из таблицы, используя первичный ключ! Спасибо администратору базы данных, что вы спасатель ». Так что в этом сценарии действительно все, что вы делаете, - это создаете много работы за небольшую ценность.

Во-вторых, это просто больше работы для группы БД. То, что, вероятно, произойдет, даже если они действительно смотрят на другие вещи, они собираются быстро взглянуть на это, и что-то будет пропущено. Они занятые люди, и просмотр кода действительно отнимает много времени. По правде говоря, это несправедливо, когда им поручают это, потому что для всех остальных это оправдание быть ленивым и использовать их как аут, что в конечном итоге и происходит. Что-то ломается в производстве, и разработчик быстро указывает: «Ну, администратор базы данных рассмотрел это». Сейчас это верно все время, нет, но это верно время от времени и часто от людей, которым необходимо действительно пересмотреть свой код. Таким образом, вы похоронили DBA с дополнительной работой и заставили этого человека отвечать за чужие ошибки, когда этот человек, вероятно, не '

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

kemiller2002
источник
2

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

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

Ян
источник
0

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

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

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

Анджей Бобак
источник
0

В нашей команде разработчиков есть подгруппа из 4 разработчиков баз данных, имеющих опыт работы с платформой СУБД, которую мы используем. Они пишут все SQL или, по крайней мере, рецензируют и вносят изменения в соответствии со стандартами кодирования любого SQL, написанного разработчиками .Net. Они являются частью команды проекта. Производственные администраторы баз данных принадлежат совершенно другому отделу, и их работа является оперативной. Они не проверяют наш код или схему SQL, и даже развертывание выполняется по сценарию, все, что они делают - это запускают сценарий. Больше всего они помогают в настройке производительности.

softveda
источник