Кожен оператор SQL повинен переглядатись за допомогою DBA - загального?

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

Якщо ви опинилися в такому середовищі, чи вважаєте ви це чистим прибутком чи затягом розвитку? Оскільки хтось, хто вже багато років працює з реляційними базами даних, я вважаю, що "розробникам не можна довіряти використання баз даних", це не є обґрунтованим, і мені цікаво, наскільки поширена така ситуація. Для чого це варто, це лише розробка веб-сторінок, а не щось критичне.

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

В цілому ми шукали:

• Використання індексу - чи виконував запит повне сканування таблиці?
• Ремонтопридатність - чи потрібно буде запит змінити через пару тижнів, оскільки щось було важко закодовано? І чи читається запит?
• Загальна ефективність - чи можна замінити внутрішнє з'єднання існуючим? Чи додали б довідку з блоком?
• Проблеми з блокуванням - чи запит заблокує базу даних і не дозволить робити оновлення? Це сталося більше, ніж мені цікаво думати.

Частіше за все у більшості запитів не виникало проблем, і ми продовжували їх працювати. Але кожен огляд займав від 10 хвилин до двох годин, залежно від запиту. Частині мені сподобалась ідея робити огляди, тому що це завадило жахливий телефонний дзвінок о 2 ранку, оскільки якийсь звіт викликав проблему з іншою програмою. Але в той же час я подумав, що це трохи непосильно, тому що ми всі дорослі, і людина, яка пише запит, повинна робити все, що потрібно.

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

Оновлення У моїй першій роботі всі запити були написані DBA, і це було головним вбивцею часу на розробці. Мені довелося подати всі потрібні стовпці, таблиці, де розташовані стовпці, і нарешті мої критерії пошуку. Навіть основні заяви вставлення / оновлення / видалення, необхідні для проходження DBA. Врешті-решт я дійшов до того, що я міг би написати SQL, який я хотів, поглянути на нього і внести будь-які необхідні зміни, а потім обернути навколо нього збережену процедуру, але це було лише пару років. Саме ця компанія найняла багато останніх випускників коледжів, і це було те, як вони гарантували, що нові хлопці не пишуть запити, які вбивають виставу.

Це повністю залежить від навколишнього середовища, галузі та компанії.

Деякі приклади:

• У НАСА стандартні декілька рівнів перевірки та огляду. Найвідомішим "повинен був двічі перевірити", коли зонд був відправлений на Марс, а США зробили розрахунки в футах, але європейці в метрах. Зонд був загублений.

• При запуску без DBA (поширений в ці дні) не буде огляду DBA і, можливо, навіть немає огляду програміста (наприклад, якщо в компанії немає інших програмістів).

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

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

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

• Скільки часу витрачає розробник на витягнення sql з коду та підготовку до подання до DBA
• Скільки часу DBA займає перегляд sql?
• Як часто запитуються зміни DBA? Розбитий за
  типом запиту ?

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

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

Розробники живуть у світі, що оптимізується - це зло. Такий настрій не працює, коли ви виконуєте операції з диском. Цей набір розуму не працює, коли ви вибираєте тип даних, який у 8 разів більший, ніж повинен бути, що призводить до того, що індекс буде в 8 разів більшим, ніж повинен бути, тому він більше не може вписатися в пам'ять. Такий настрій не працює, коли ви програмуєте на загальний API, який надмірно оновлює всі стовпці таблиці (немає дяку Java-бобів).

Вони не знають, що таке сканування повного столу. Вони не знають, як обробляти дані за одну операцію набору, а не відкривати курсор. Гірше, ніж курсор, вони запитуватимуть дані, а потім по черзі оброблятимуть його назад і назад до бази даних, коли вистачить одного простого оновлення простого джейн. Результатом цього є ГРОМОВА продуктивність.

Вони не знають серйозного впливу звітності за великими таблицями. Можливо, потреба у звітах зажадає створення зіркової схеми та подачі в неї даних. Ваш середній розробник просто запитає таблиці exisitng і запитає, чому для запуску запиту потрібно 3 години (це реальна цифра).

Знань, якими володіє ваш середній розробник, вистачить для «середніх» додатків CRUD, де користувач просто редагує запис. Це буде недостатньо, як тільки вони вирвуться з міхура Ruby-on-Crack і перейдуть у реальний світ.

Залежить від того, наскільки велика база даних, і якщо вона поділяється між кількома програмами. Часто команді DBA подобається знати, які запити будуть виконуватися, щоб вони могли переконатися, що відповідні індекси встановлені, або вони знають, кого повідомити, якщо їм потрібно розділити таблицю. І вони, як правило, трохи кращі, ніж середній розробник, читаючи плани виконання запитів та визначаючи місця, де можна вказати підказки для підвищення продуктивності. Це також є шансом зрозуміти, що деякі запити з високим впливом будуть надходити в наступному випуску, щоб вони могли збирати різні статистичні дані для оптимізатора.

Я не працював у такому середовищі, ні я.

Існує різниця між командною роботою та ворожою бюрократією. Як розробник, я хотів би отримати вкладку DBA у складні запити. Але я знаю, коли звернутися за допомогою.

Якщо я недостатньо компетентний для простих SELECTзапитів, мене слід звільнити.

Я бачив це в кількох різних місцях. Теоретично це чудово, але я рідко бачив, що це ефективно. Ось чому. По-перше, якщо у вас є команда DBA (або інших людей), я, як правило, виявив, що найменш компетентний або найменш сподобався чоловік у групі отримує основну увагу в роботі з огляду. Чому, кажете ви? Це тому, що ніхто більше не хоче цього робити, а всі інші зайняті тим, що роблять інші речі, які, ймовірно, є більш нагальними. Коли-небудь бачив, як DBA сидить навколо і каже: "Людина, все працює ідеально; я можу просто сидіти і переглядати мережу. Мені б хотілося щось робити" Я теж, принаймні, не хороші. Вони настільки ж зайняті чи зайнятіші, ніж усі. Це означає, що найменш здібний чоловік, швидше за все, робить огляд, і це саме той, кого ви не хочете робити. Код, який ви хочете переглянути, це дійсно важкий код, який люди розглядають і передають його як якусь чорну магію. Молодші DBA або просто погані, ніколи не зможуть зрозуміти тонкощі того, як працює справді важкий запит. Рідко, як ніколи, хтось ніколи не каже: "Людина, я не думав вибирати один рядок із таблиці за допомогою первинного ключа! Дбакую DBA, що ти рятувальник". Тож у цьому сценарії дійсно все, що ви робите, - це створити багато роботи за малу цінність. не думайте вибрати один рядок із таблиці за допомогою первинного ключа! Дякую DBA, що ти рятувальник. "Отже, у цьому сценарії справді все, що ти робиш, - це створити багато роботи для малоцінного. не думайте вибрати один рядок із таблиці за допомогою первинного ключа! Дякую DBA, що ти рятувальник. "Отже, у цьому сценарії справді все, що ти робиш, - це створити багато роботи для малоцінного.

По-друге, це просто велика робота для групи DB. Те, що, мабуть, станеться, навіть якщо вони дійсно дивляться на інші речі, - це вони швидко поглянуть на це, і щось буде пропущено. Вони зайняті люди, і перегляд коду дійсно забирає багато часу. По правді кажучи, це не справедливо, що вони отримують завдання з цього завдання, тому що це привід для всіх інших лінуватися і використовувати їх як вихід, що в кінцевому підсумку і відбувається. Щось перерва у виробництві, і розробник швидко зазначає: "Ну, DBA переглянув це". Зараз це правда весь час, ні, але це правда частина часу і часто від людей, яким потрібно перевірити свій код. Таким чином, ви поховали DBA додатковою роботою і змусили цю людину відповідати за чужі помилки, коли ця людина, ймовірно, не робить '

Єдиний спосіб реально вирішити проблему - це люди, які вміють писати SQL-код, писати її. Чи повинні вони час від часу отримувати дані від DBA? Звичайно, вони повинні, але я завжди знаходив, якщо ви не встигнете зробити це правильно в перший раз, коли ви збираєтеся знайти час, щоб виправити це.

Я працював у такому середовищі. Усі зміни системи були рецензовані відповідними колегами. Для мене це просто означало, що я повинен запланувати заздалегідь і подати свої зміни за кілька днів до цього. SQL перейшов до DBA, які в кінцевому рахунку випустять SQL у виробництво.

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

Я б навіть пішов далі. Я перевірив би навколишній код і побачив, як змінні передаються до запиту. Часто можна спостерігати, як розробники піддають їх застосуванню на sql-ін'єкційні атаки через відсутність базових знань (помилкові припущення "цього не можна зламати").

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

У останньому проекті, над яким я працюю, жодному передньому розробнику не дозволяється безпосередньо отримувати доступ до бази даних. Вони підвищують попит на функцію, що повертає заданий набір даних, і розробники бек-енду готують їх до них. Це працює досить добре, передні розробники записують користувальницький інтерфейс та обробляють дані, що надаються функціями, записаними задніми розробниками.

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