Чи повинні досвідчені програмісти знати запити до бази даних? [зачинено]

35

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

Чи повинно це бути головною вимогою бути експертом-програмістом чи програмним інженером?

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

database query

— Шамім Хафіз
джерело

2

Що ви маєте на увазі під "структурою"? Якщо ви говорите про семантику, то сприйняття будь-якої нової семантики не повинно бути проблемою для " експерта ". За визначенням. ОТОХ, лише деякі розробники стикаються з базами даних та мовами запитів, решта нас взагалі не хвилюються.

— SK-логіка

3

Я думаю, що це помилкове припущення: "Там так багато програмістів, які також є експертом із написання запитів та дизайну баз даних". Програмістів, які знають ці речі, є порівняно мало: DBA! = SE.

— Ешлі

1

Наскільки важко насправді писати запити до бази даних?

— Капітан Чутливий

@CaptainShakespeare, насправді це може стати досить важким, як тільки ти пройдеш операції CRUD. Тай займається складною звітністю. А потім подивіться запити налаштування продуктивності.

— HLGEM

69

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

Отже, якби я зустрів програміста, який не знав, як написати запити до бази даних, я очікував би одного з двох:

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

Запити до бази даних принципово відрізняються від більш стандартних мов програмування. Вони алгебраїчні і призначені для роботи з реляційними даними, тоді як C # або Java є обов'язковими і працюють на дисках, пам'яті, введенні користувачами і т.д.

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

Їх команда використовувала ORM / NoSQL
У їх команді були програмісти БД
Складність програми полягала в логіці бізнесу, а запити БД були тривіальними
Їхня команда розподіляла роботу так, що деякі програмісти не писали запитів

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

Підсумовуючи це, більшість досвідчених розробників повинні знати запити до бази даних .

— Матвій Родатус
джерело

1

Отже, якщо хтось зробив нетривіальний проект, який використовував Базу даних, його, як очікується, ознайомлять із запитами, правда?

— Шамім Хафіз

3

@Shamim, я б очікував, що ця людина буде досвідченою щодо запитів, якщо ця людина не була молодшою чи початковою. Можливо, ця людина має лише декілька років досвіду і була притулена до вузькоспеціалізованої команди?

— maple_shaft

12

@Shamim, я б, напевно, очікував цього. Вони все ще можуть бути хорошим програмістом. На такі питання дуже важко відповісти, тому що в них так багато застережень: можливо, в команді був програміст БД; можливо, нетривалість програми була в діловій логіці, а запити до бази даних були тривіальними; можливо, вони розподілили роботу так, щоб ваш програміст не працював над запитами; пр.

— Матвій Родатус

4

Моя команда розробників виділила програмістів PL / SQL як частину проекту. Тому, хоча програмісти .Net можуть робити прості запити, вони є там, щоб переглянути його та розробити більш складні запити. Крім того, з розповсюдженням ORM (і NOSQL) чому ви вважаєте, що розробники, які не використовують SQL, повинні знати складні запити.

— softveda

2

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

— Девід Торнлі

23

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

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

— wolfgangsz
джерело

1

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

— SK-логіка

8

Це підсумовує і мою думку. Експерт? Ні. Знання? Так.

— Уейн Моліна

2

@ SK-логіка. Які варіанти ви вважаєте, що реляційні бази даних не мають значення? Захоплення даних є надто спеціалізованим для того, щоб аналітика була корисною в транзакційній системі. І не запускайте мене на все, що не так з OODBMS.

— maple_shaft

1

@maple_shaft, існує чимало спеціалізованих рішень для зберігання даних, орієнтованих на домен. RDBMSes намагається бути загальним, і в цьому погано не вдається. У деяких випадках навіть стародавні ієрархічні СУБД набагато кращі, ніж реляційні.

— SK-логіка

6

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

— Адам Лір

18

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

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

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

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

— HLGEM
джерело

4

+1 для згадки про те, що наявність ORM не замінює необхідності знати SQL (або основні фактори в будь-якому типі db, який ви використовуєте).

— RHSeeger

4

+1, і я хотів би, щоб я міг тобі дати ще 100! Я знаю, що кореляція! = Причинний зв’язок, але мені більш ніж очевидно, що найефективніші розробники додатків, з якими я колись працював, мали глибоке розуміння того, як написати стандартний запит SELECT. Я повинен мати можливість передати хорошому розробнику модель даних та "питання" про дані, і ця людина повинна врешті-решт мати можливість написати запит, який "відповідає" на моє запитання.

— maple_shaft

1

+1, повністю згоден. Я не купую пояснення, що "ми використовуємо ORM" або "у нас є спеціальні програмісти для цього". Якщо хтось справді досвідчений , він би заповнив роль розробника db в один момент. Ось який досвід.

— GrandmasterB

15

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

По-друге, якщо є DBA або автори запитів повного робочого дня (незалежно від назви), розуміння також має менше значення.

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

Моя особиста думка: Ні. Досвідчений розробник програмного забезпечення повинен мати можливість засвоїти нові навички (наприклад, SQL), якщо і коли потрібно, а не "за замовчуванням". Гнучкість та здатність вчитися та розуміти - це, що відрізняє хорошого розробника від нормального. Правило "золотого молотка" також застосовується - якщо у вас є розробник з широкими знаннями SQL, велика ймовірність, що цей розробник витягне інструмент, який він найкраще знає - реляційні бази даних - щоб спробувати вирішити кожну проблему, хоча це не обов'язково має бути найкращим рішенням. Звичайно, це стосується і прихильників NoSQL,;).

Підбір правильного інструменту для правильної роботи - це те, що повинен знати досвідчений програміст.

— Ктулху
джерело

Бази даних NoSQL не обробляють більше даних або швидше, ніж реляційні. Я не знаю, де ви це чули, але це очевидно, небезпечно неправильно.

— Aaronaught

@Aaronaught - Відредаговано, дякую за підсумки мого передчасного припущення, :).

— Cthulhu

7

Перегляньте це вступ у Вікіпедії до Комп'ютерного програмування:

Комп'ютерне програмування (часто скорочене до програмування чи кодування) - це процес проектування, написання, тестування, налагодження / усунення несправностей та підтримання вихідного коду комп'ютерних програм. Цей вихідний код написаний мовою програмування. Мета програмування - створити програму, яка проявляє певну бажану поведінку.

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

Тому я думаю, що це програмування, безумовно.

— guiman
джерело

7

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

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

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

Переважна більшість систем бізнесу та бізнесу, на мою думку, не виправдовують необхідність моделювання даних та спеціалізованих програмістів баз даних, але я працював над такими проектами до того, як ВЕЛИКОБРИТИЙ користувався знаннями та досвідом, які ці люди принесли до столу.

— кленовий вал
джерело

2

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

— Джон Сондерс

3

Ви все ще не погоджуєтесь, якщо я скажу, що хороший інженер програмного забезпечення ПІДПРИЄМСТВА або БІЗНЕС-програми (на відміну від вбудованих систем тощо), і якщо я сказав, що ця людина повинна бути експертом зі стандартних запитів реляційних баз даних (без постачальників фантазійних штанів) специфіки, такі як аналітичні запити тощо)? ГОЛОВНЕ розуміння операторів SQL SELECT, усіх типів з'єднань, об'єднань, пересічень та злиття, вбудованих поглядів, умов, упорядкування та групування наборів результатів повинно бути чітко зрозуміло та чітко продемонстроване будь-яким інженером програмного забезпечення, який має мітки, які я вказав вище.

— maple_shaft

4

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

— Адам Лір

2

Я стою біля того, що я сказав. Теоретично, якщо додаток є багаторівневим та компонентним, тоді немає необхідності, проте в усьому моєму професійному досвіді моя команда, і я би ВІДМОВИЛА, якби ми не були фахівцями SQL, навіть коли у нас була спеціальна команда з розробки та розробки RDBMS. Можливо, я старомодний або просто маю страшну удачу в кар’єрі?

— maple_shaft

3

@maple_shaft Так, це не те, що програми, над якими я працював, були досить складовими. Це те, що вони не використовували жодного RDBMS, періоду. Думаю, різні поля. Справа в тому, що ви не можете сказати, що кожен розробник бізнесу / підприємства повинен бути хорошим у SQL. Це просто неправда. Будьте добрі в цьому, якщо використовуєте. Не переживайте занадто сильно, якщо вам цього не потрібно, як і для будь-якої іншої мови чи технології.

— Адам Лір

6

Інші вже відповіли на ваше запитання щодо запитів до бази даних.

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

Місце, де я зараз працюю, має таку саму конструкцію бази даних, яку вона мала в 1970 році. Ми перенесли базу даних з IDMS в DB2, але це та сама конструкція мережевої бази даних. У мене була можливість створити 5 нових таблиць DB2 за 9 років роботи тут.

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

— Гілберт Ле Блан
джерело

5

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

Інші згадали про багато способів, як ми можемо уникнути тонкої зернистості SQL у своїх робочих місцях, навіть коли ми працюємо (опосередковано) з базами даних, але що робити з усіма розробниками, які пишуть прошивку для 101 електротехнічної продукції, яку ми кожен з них володіти? А як щодо хлопців, які спеціалізуються на моніторингу в режимі реального часу?

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

— cjmUK
джерело

5

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

Багато класів застосування не орієнтовані на бази даних.

Чи потрібна нам СУБД у текстових процесорах та редакторах зображень? Що щодо систем розпізнавання мовлення та комп'ютерного зору, чи містять вони багато запитів до бази даних?

А що з лінійними відеоредакторами та фізичними двигунами відеоігор?

— Олексій Жасмін
джерело

5

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

— Баррі Браун
джерело

4

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

Однак, якщо цей програміст може написати лише запити типу "select * from tblxxxx", я б не вважав цього програміста експертом. Так само, якщо база даних, розроблена цим програмістом, розміщує відносини один на багато в одну таблицю замість двох таблиць, я б не вважав цього програміста експертом.

Ось як я пояснюю це не ІТ-людям. ІТ-фахівці спеціалізуються на певних сферах, подібних до того, як тесляри, електрики та сантехніки спеціалізуються на шанованих сферах. Вони, як правило, перекривають деякі навички, але не є експертами у всіх сферах. Електромонтажник може з упевненістю виконувати прості столярні завдання, але не буде нічого доброго, намагаючись вирішити складні конструкції.

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

— Майкл Райлі - AKA Gunny
джерело

3

Озираючись у нашому відділі, це залежить:

Наші розробники настільних / веб / серверів . Принаймні, потрібно писати основні до передових твердих заяв залежно від їх спеціальності. Для оптимізації у нас є кілька спеціалізованих адміністраторів БД.
Наші вбудовані програмісти . Дуже кілька разів не проходило "вибирати * з mytable". Однак це також змінилося в останні кілька місяців із впровадженням sqllite у свої проекти.

— Карра
джерело