що роблять програмісти баз даних?

Щоразу, коли я читаю про програмістів Oracle тощо, я плутаюся. Я не знаю, що саме вони роблять.

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

У цьому відношенні, чи не програмування баз даних в основному не створює таблицю, і чи не обробляються ці таблиці у відповідь на оператори SQL, які видаються додатком, який зазвичай є лицьовим? Тож чи є створення столів такою великою справою?

Щоб по-справжньому оцінити, які програмісти баз даних насправді повинні самі пройти - дозвольте спробувати пояснити це іншим способом.

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

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

• Програмістам потрібно вирішити, як слід структурувати додаток
• Перетворення вимог у те, що розуміє комп'ютер, часто далеко не банальне.
• Програмісти повинні знати про наслідки для продуктивності
• Оскільки програмісти набувають досвіду використання своєї платформи за вибором, вони стають більш досвідченими, швидше передаючи код високої якості.

(Звичайно, це дуже скорочений список, я просто намагаюся підібрати точки, які мають паралелі в розробці бази даних)

Добре розробка бази даних майже однакова - для погано поінформованих це виглядає досить просто, але як тільки ви більше залучаєтесь, ви усвідомлюєте конкретні ускладнення розробки бази даних:

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

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

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

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

Вони виконують запити мелодії. Я змінив запити, які запускають хвилини до мілісекунд. Я змінив процес, який тривав протягом 24 годин, і тривав менше ніж 30 хвилин. Вони розробляють та підтримують структуру індексування, яка буде врівноважувати швидкість вставки та швидкість вибору.

Вони пишуть складні запити, особливо запити звітності. Я особисто написав запити, що мають понад 1000 рядків через складність вимоги. Їм все одно довелося і швидко бігали.

Вони створюють сховища даних та супутні ETL процеси для їх підтримки. Часто їм потрібно записати процеси, щоб надсилати дані з інших джерел, і вони повинні з'ясувати, як зіставити поля з деяких баз даних клієнтів у їхні, і це ніколи не є близькою відповідністю за типом даних, розміром даних, необхідними полями, значеннями пошуку, тощо.

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

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

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

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

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

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

Це досить просто. Якщо ви чули про подібну схему MVC, ви повинні знати різницю між вашими контролерами та моделями. Наприклад, якщо ви пишете ERP, тоді уявіть, що у своєму контролері ви просто скажете "retrieveCashFlow" для вашої моделі, і ваша модель викликає збережену програму в базі даних. Ця збережена програма піклується про кожне об’єднання, фільтрацію, замовлення тощо, і ви отримуєте оброблені дані назад. У вашому контролері ви просто повинні разом розмовляти речі.

Якщо у вас є сумніви щодо збережених процедур, перевірте це: навіщо використовувати збережені процедури?

Простіше кажучи: розробники баз даних записують збережені програми (процедури та функції) для вашої програми, щоб піклуватися про M в MVC (або про бізнес-логіку, якщо ви не використовуєте mvc).

Oracle - це не просто база даних, а повноцінне середовище програмування, включаючи форми та дизайнери звітів. Як програміст Oracle, ви програмуєте повноцінні програми для користувачів. Кодування бази даних, на яке ви посилаєтеся, часто робиться спеціалізованими адміністраторами баз даних (DBA).

Sybase Я думаю, це ще один із схожими середовищами програмування.

Інші бази даних можуть обмежуватися "просто", що дозволяє визначати та виконувати звіти, тоді як інші можуть взагалі не пропонувати будь-які форми або засоби проектування / виконання звітів.

Я б сказав, що розробник бази даних несе відповідальність за одне або декілька з наступного

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

Залежно від RDBMS, про який йде мова, він може включати такі завдання, як

• Створення звітів та форм
• Створення потоків для імпорту / експорту даних

Подивіться на цей список відповідальності