Ванкуверская Беседка
-
По запросу SQL developer всплывают вакансии программистов всех мастей, и составить какую-то типичную картину сложно.
Чтобы вы понимали к чему у меня лежит душа:
Я пользуюсь простенькой CMMS (computerised maintenance management system), по сути управление ремонтной базой данных (список обородувания, запчастей, наряды-допуски и т.д. и т.п., и всё это склеено в одну взаимосвязанную систему. Такой SAP в миниатюре и чисто для Maintenance), и у меня всегда была и есть тяга её совершенствовать, подстраивать под себя и т.д. но за неимением соответствующих навыков, я всегда скатываюсь до каких-то костылей в виде spreadsheets с какими-то формулами и pivot tables...
Вот из этого бэкграунда у меня выросло желание идти в базы данных, софт по управлению ими и т.д. В моем понимании SQL и т.д. это как раз то, что надо?..
-
Ок, тогда кто эти люди на YouTube, которые рассказывают про их переход в IT (из не IT) путем обучения в направлении SQL?.. 🤔🙂 Я без сарказма если что
-
Что есть "нормальный язык", если задачей стоит писать программы, заточенные на упраление большими взаимосвязанными списками данных (не анализировать, а манипулировать)
-
смекалочка это важный скилл! ))
-
Манипуляция данными это, кажется, Data Engineer называется, может больше поможет в гуглеже
-
Спасибо, именно эту закономерность я часто и вижу. Но я бы хотел не анализировать эти данные, а строить инструменты для создания/изменения/манипуляции этих баз данных
-
Любить играть в игрушки != любить писать игрушки. Не хочу ломать настрой, но "идти в базы данных" это полноценная профессия, очень широкая и с соотв. затратами. SQL важен, но скорее всего речь также об умении дизайнить БД. А дизайн баз данных это уже ощутимо сложнее, чем просто выучить SQL. Ну или можно сюда и бекенд программирование добавить. Как уже советовали, лучше мониторить рынок на предмет вакансий и изучать что ищут. Если речь идет о хобби. то это хобби на всю жизнь.
-
Согласен, те DBA которых я знаю занимаются архитектурированием и масштабированием баз, тюнингом для оптимизации времени исполнения и прочими штуками типа контроля над race conditions. Созданием таблиц занимаются сами разработчики
-
Вот у меня то же мнение. Последнее время тенденция смещения к контролю запросов и структуры в сторону разработки. Сервисы обычно завязаны на это очень сильно и разделение ответственности начинает только вредить.
-
Я честно могу сказать что не знаю никого кто сразу становился DBA. Мне кажется надо начинать с какого-то программирования а потом уже специализироваться в базы
-
Я наоборот, из 12 DBA знакомых/коллег никого не знаю, кто из разработки перекатился, в основном это либо бывшие админы, либо те у кого в универе был хороший курс по базам/ораклу 🙂 Другое дело, что профессия DBA в списке на отмирание - в крупных и энтерпрайз они наверное еще долго нужны будут, но мелким/средним компаниям проще использовать AWS RDS/GCP Spanner или Oracle Cloud, для аналитики BigQuery/Snowflake и просто подкидывать ресурсов если перфоманса не хватает. В этом случае DBA-задачи сводятся к базовым и перекладываются на разработчиков, похожее уже произошло и с QA, и c DevOps
-
Dba не отмирают, они еволюционируют. Как и всё в этом мире. Увеличение объема данных для хранения и обработки сместили челендж в сторону распределенных систем. Грубо говоря, всё перестало умещаться на один супер мощный сервер. Теперь серверов тысячи. Они раскиданы по всей планете. Инфраструктурную часть покрывают облачные сервисы. Но DBA все равно анализируют домен, выбирают подходящую базу(ы) для задач и создают модели данных. А также мониторят состояние этого всего. Наверное они уже и не DBA называются. Профессия разделилась на несколько направлений.
-
В общем, я вроде как понял пару вещей:
-
я прям с проходняка взял прицел на очень узкоспециализированную нишу...
-
классические спецы (DBA, архитектура и т.д.) в малом и среднем бизнесе не водятся за ненадобностью, и в целом это вымирающий вид (по крайней мере в классическом его варианте).
Тогда вопрос:
в какую часть IT стоит идти человеку, у которого есть желание строить инструменты для взаимодействия с базами данных.
Сценарий:
Упрощённо, вот есть небольшая компания, которая ведёт учёт всего и вся в 30-50 мерзко оформленных, разрозненных excel простынях, растыканых по сетевым дискам. И тут они решают, что хорошо бы все централизовать и закупить какой-нибудь софт, а ещё лучше построить что-то простенькое под себя... Вот каким набором СОВРЕМЕННЫХ инструментов должен обладать программист, чтобы решить задачу ? Я понимаю, что на рынке дофигище готовых вариантов, но просто хочу понять какими инструментами пользуются люди/компании, которые разрабатывают подобный софт, ибо именно туда меня тянет (по крайней мере в теории).
-
-
такую компанию с потрохами съедят сейлзы из каких-нибудь SAP или Salesforce 🙂 ну или игроки поменьше, если успеют. Мне сложно представить, чтобы компания наняла одного программиста решать эту задачу написанием кастомных тулов
