Признаки отличного SQL-разработчика
Исходя из их работы, как отличить хорошего разработчика SQL?
Примеры могут включать:
Редко использует КУРСОРЫ и пытается их реорганизовать. Редко использует временные таблицы и пытается их реорганизовать. Уверенно обрабатывает значения NULL во ВНЕШНИХ СОЕДИНЕНИЯх. Избегает расширений SQL, которые не получили широкого распространения. Умеет делать отступы элегантно.
Можете ли вы привести пример операции бизнес-процесса, для которой вы сейчас используете курсор?
2 000 сотрудников бизнес-единицы 103 имеют право увольнения с 01 марта 2012 года. Я хочу добавить действие найма для этих сотрудников на 02 марта 2012 года и обновить их платежные ведомости. Некоторые поля в самых высоких записях для каждого сотрудника будут перенесены в новые действия и записи. Как я могу получить данные о действиях сотрудников и платежные ведомости без курсора? Система имитирует систему Peoplesoft, если это помогает.
Разве вы, естественно, не сделали бы что-то вроде SELECT fields FROM terminations WHERE business_unit = '103' AND action_date = '01 -MAR-2012 '? Затем используйте это для создания «INSERT INTO rental_actions (fields ....) SELECT и т. д.» (добавление объединений и выражений по мере необходимости? А для записей о заработной плате выберите SELECT из самой высокой записи для создания операторов INSERT и UPDATE? Вам, вероятно, потребуется проделать примерно то же самое даже с курсором. Просто сделайте из него операцию набора, чтобы обрабатывать всех сотрудников в одном заявлении.
Ах. Понятно. Рекомендуется поместить весь код в один оператор SQL. Для простых обновлений это может быть нормально, но для программ, требующих более сложной логики, которая потенциально может сделать SQL довольно громоздким и трудным для устранения неполадок. Заставляет меня вернуться и проверить свои старые программы. Когда у меня будет время, я пойду и посмотрю, можно ли что-то оптимизировать. Благодарю за разъяснение.
Речь идет не о том, чтобы поместить это в один оператор, а о написании SQL на основе наборов. Все реляционные БД посвящены ТЕОРИИ МНОЖЕСТВ. Курсоры - это тип цикла, означающий, что операция работает с одной строкой, а затем проходит через все строки в вашем наборе данных. Вы можете не заметить этого на небольшом наборе данных, но это крайне неэффективно и работает против оптимизаторов в ядре базы данных. SQL - это декларативный язык, вы говорите, что хотите добиться успеха, а не как этого добиться. Курсоры нравятся программистам, потому что циклы знакомы, но они не масштабируются в SQL; они злые.
Ответы 5
Я не думаю, что курсоры, временные таблицы или другие методы SQL изначально плохи или что их использование является явным признаком того, насколько хорош программист баз данных.
Я думаю, что есть подходящий инструмент для решения любых проблем. Конечно, если у вас есть только молоток, все будет похоже на гвоздь. Я думаю, что великий программист SQL или разработчик баз данных - это человек, который знает, какой инструмент является правильным в конкретной ситуации. ИМХО нельзя обобщать, исключая конкретные закономерности.
Но практическое правило может заключаться в следующем: отличный разработчик баз данных найдет для сложных ситуаций больше короткое и элегантное решение, чем средний программист.
Вот несколько вещей, которые не относятся к рядовым разработчикам программного обеспечения, но применимы к тем, кто хорошо владеет SQL:
- Определяет полезные индексы, но не избыточные или неиспользуемые индексы.
- Эффективно использует транзакции.
- Ценит ссылочную целостность.
- Применяет нормализацию к дизайну базы данных.
- Думает наборами, а не петлями.
- Уверенно использует JOIN.
- Знает, как работает NULL и трехзначная логика.
- Понимает использование и преимущества параметров запроса.
Приведенные вами примеры неиспользования курсоров, временных таблиц или знания трех альтернативных запросов для данной задачи, я бы посчитал нет признаками того, что вы являетесь отличным разработчиком SQL. Возможно, я бы назвал того, кто занимается такими вещами, «акробат».
Это признаки хорошего разработчика SQL, но я не думаю, что их достаточно, чтобы отличить «великого» разработчика.
Хорошо, с определением, что есть консервативные акробаты и глупые акробаты.
Да, я имел в виду именно это. Акробат может продемонстрировать впечатляющее мастерство, мастерство и талант. Но часто есть более простые способы добраться из пункта А в пункт Б.
Я обнаружил, что отличный разработчик SQL обычно также является отличным дизайнером баз данных и предпочитает участвовать как в проектировании, так и в реализации базы данных. Это потому, что плохой дизайн базы данных может расстроить и сдержать даже самого лучшего разработчика - хорошие инстинкты SQL не всегда работают правильно перед лицом патологических проектов или систем, в которых RI плохой или отсутствует. Итак, один из способов рассказать об отличном разработчике SQL - это протестировать его на моделировании данных.
Кроме того, хороший разработчик БД должен иметь сложную логику соединения и точно знать, какими будут результаты различных многосторонних соединений в разных ситуациях. Недостаток комфорта с объединениями - причина №1 плохого кода SQL (и плохого дизайна SQL, если на то пошло).
Что касается конкретных синтаксических вещей, я бы не стал использовать такие директивы, как:
Does not use CURSORs.
Does not use temporary tables.
Использование этих методов может позволить вам отличить опасного программиста-любителя SQL (который использует их, когда простые реляционные предикаты были бы намного лучше) и достойного начинающего программиста SQL (который знает, как делать большинство вещей без них). Однако в реальном мире существует множество ситуаций, когда временные таблицы и курсоры являются вполне адекватными способами (иногда единственными) для выполнения задач (за исключением перехода на другой уровень для выполнения обработки, что в любом случае иногда лучше).
Итак, использование таких продвинутых концепций не запрещено, но если вы явно не имеете дело с экспертом по SQL, работающим над действительно сложной проблемой, которая по какой-то причине не поддается реляционному решению ... да, они, вероятно, предупреждающие знаки.
Мне особенно нравится комментарий относительно неверно разбитой функциональности. Я думаю, что чаще всего используются курсоры - dbms используются для решения проблемы какого-то другого уровня.
И, как и в случае с большинством других вещей ... "это зависит от обстоятельств". Различные архитектурные и нечеткие причины могут убедить человека написать код в БД, который был бы более подходящим на другом уровне, и именно в такие моменты эти расширенные функции БД полезны.
Просто чтобы добавить к уже отличным ответам; Разработчик может свести сложную проблему к чему-то простому и прост в обслуживании.
классный, хороший общий, расплывчатый, не очень-то добавляющий никакой ценности ответ!
Знает, как использовать INFORMATION_SCHEMA и метаданные таблицы, чтобы писать общий код или код генерировать код, чтобы сохранить повторяющиеся задачи базы данных.
Кто-нибудь, пожалуйста, проясните комментарий «Редко использует КУРСОРЫ и пытается их реорганизовать»? Я работаю над системой управления персоналом среднего размера и довольно регулярно использую курсоры при массовом обновлении записей от нескольких тысяч до десятков тысяч. Как это было бы сделать без использования курсора?