Ванкуверская Беседка
-
Спасибо, именно эту закономерность я часто и вижу. Но я бы хотел не анализировать эти данные, а строить инструменты для создания/изменения/манипуляции этих баз данных
-
Любить играть в игрушки != любить писать игрушки. Не хочу ломать настрой, но "идти в базы данных" это полноценная профессия, очень широкая и с соотв. затратами. 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 🙂 ну или игроки поменьше, если успеют. Мне сложно представить, чтобы компания наняла одного программиста решать эту задачу написанием кастомных тулов
-
но кстати спецы которые внедряют эти готовые тулы клиентам, кажется, носят название Customer Success Specialist или что нибудь со словом Implementation
-
Речь не о живучести бизнес-модели "соло-программиста" 🙂 Вопрос в том, КТО он, что он умеет?
-
реалистично - скорее всего он умеет убеждать других что он сможет справиться с задачей и его решение будет отлично работать / прекрасно работает))
-
Ок, перефразирую: что этот программист умеет такого, от чего SAP и/или Salesforce вместо "сожрать" предпочтут "нанять"?
-
сори, под “сожрать” я имел в виду что они плотно возьмутся за компанию и убедят купить у них софт, после чего от них приедет человек или несколько человек, которые все это прикрутят.
