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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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