что делают программисты баз данных?

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

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

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

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

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

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

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

(Конечно, это очень сокращенный список, я просто пытаюсь найти точки, которые имеют параллели в разработке баз данных)

Что ж, разработка баз данных во многом схожа - для плохо информированных это выглядит довольно просто, но как только вы станете более активным, вы узнаете о специфических сложностях разработки баз данных:

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

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

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

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

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

Они пишут сложные запросы, особенно отчеты. Лично я написал запросы длиной более 1000 строк из-за сложности требования. Они все еще должны были бежать и быстро.

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

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

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

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

Я проходил стажировку в качестве программиста базы данных для производства данных о 24-часовом вафельном заводе в конце 90-х. Я не знаю, насколько типичными были мои обязанности, но самая большая часть для меня заключалась в том, что когда было необходимо изменить кодировку поля или схему, я должен был убедиться, что это изменение было бесшовным для производства. По сути, это означало, что я скажу им обновить их клиентское приложение, что они будут делать в удобное для них время, и ожидается, что они сразу же вернутся с новыми изменениями.

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

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

Это довольно просто. Если вы слышали о шаблоне MVC, вы должны знать разницу между вашими контроллерами и моделями. Например, если вы пишете ERP, представьте, что в вашем контроллере вы просто говорите «retrieveCashFlow» своей модели, и ваша модель вызывает хранимую программу в базе данных. Эта сохраненная программа заботится о каждом соединении, фильтрации, заказе и т. Д., И вы получите обработанные данные обратно. В вашем контроллере вы просто должны смешивать все вместе.

Если у вас есть сомнения по поводу хранимых процедур, проверьте это: зачем использовать хранимые процедуры?

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

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

Я думаю, что Sybase - еще один с похожими средами программирования.

Другие базы данных могут ограничиваться «просто» разрешением определения и выполнения отчетов, тогда как другие могут вообще не предлагать какие-либо формы или средства разработки / выполнения отчетов.

Я бы сказал, что разработчик базы данных отвечает за одно или несколько из следующих

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

В зависимости от рассматриваемой СУБД она может включать такие задачи, как

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

Взгляните на этот список обязанностей