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

С П, увы, не закончила. Уж не знаю, хорошо это для тебя или плохо. Вот, сижу, занимаюсь пожарной разработкой в сроки, за которые никто не берется, поскольку все разводят руками и ничего не понимают, и только объяснить команде, как что должно работать, и почему -- это одна-две недели. А принимать решение о разработке, проектировать программу, разрабатывать и сдавать готовый продукт заказчику у меня было всего несколько дней.

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

В результате у меня в пятницу утром обходной пyть был готов, сегодня установлен у заказчика. Угадай, что мне выдали по 5 задачам, при условии, что разработчик далеко даже не старшее звено, а специалист очень высокого уровня. В воскресенье было прорешано, но не полностью протестировано две из них, возникли вопросы. Мы их обсуждали по телефону. Разумеется, у заказчика таких сроков нет, и сегодня я уже на свой страх и риск закинула наскоро разработанный "обходной". Небольшую корректировку делала "на живую". Все работает.

Теперь жду остальное для более качественного решения, но основной пожар потушен.

Давай, валяй про преимущества специализации разработчиков.

Dark Night, Вы берёте узкий круг задач, которыми занимаетесь именно вы. А как одному спецу разобраться в трёхзвенных структурах? Где есть процедуры в БД, есть код на сервере приложений и есть код на скрипте для броузера? Конечно это возможно, но такие спецы как правило знают вообще, но в каждой конкретной области слабее узких специалистов. Потому и набираются команды и разрабатываются API, для общения между подсистемами.

Сергей, я прекрасно понимаю проблематику сегодняшней разработки, хотя в полной мере в технологии и не участвую. Действительно, технологий на сегодня существует даже слишком много. Но находясь вне технологической цепочки, я вижу ее тотальную неэффективность, которая держится исключительно на западных высокооплачиваемых традициях. Как только перестанут плaтить сверхдоходы, руководство IT-фирм будет вынуждено сокращать штат втрое. Вот тогда и начнут плaтить кадрам, которые задачу видят в целом, вглубь и вширь, а линейные программисты будут вынуждены не только свой код знать, но и как минимум иметь представление о том, что делается в соседних рабочих группах, и сносно знать то, что делается в их группе. А также хоть на каком-то уровне владеть смежными стеками.

Я встречала разных специалистов разной квалификации. Если под термином "слабее" понимать "знают меньше стандартных библиотек", то соглашусь, это так. А вот если понимать умение писать программу, а не кодить код -- то не соглашусь категорически. И когда такие программисты задают вопрос, почему у них программа не работает, то я их просто прошу показать текст. И, не зная язык в деталях, не имея представлений о вызываемых библиотеках и их функционале, я четко поясняю, откуда может возникнуть ошибка, где она может находиться, а если мне дают код детально, то показываю место ошибки и говорю, как ее можно исправить. Это касается и скриптового кода, и кода сервера, и баз данных, и файловых структур, и многих других элементов информационных систем (документов, таблиц, изображений, схем и проч.

Резонно задать вопрос: а если меня посадить за проектирование, смогу ли я заменить разработчика? Я знаю ответ. Когда нам нужно было разработать информационную систему на уровне прототипа с нуля за 2 месяца, а выдать продукт за 5 месяцев, и у нас не было ничего, даже технического задания, и у меня в команде был только один разработчик, все, что я спросила -- на каком языке пишешь и в какой СУБД ты хорошо ориентируешься? Взяла книгу, через 2 недели знала язык, через 4 было готово основное алгоритмическое ядро системы, проект был сдан в срок. Работали вдвоем, разбив задачу крупноблочно, и помогая друг другу в случае проблем.

Сергей, программирование, как и любая инженерная специальность, требует опыта. Я с этим не спорю. Никогда не измеряла, сколько лет я знакома с тем или иным языком и на каком уровне. В языке Java не писала, ничего принципиально нового в нем не заметила; будет необходимость -- придется писать и на Java. Кстати, насчет SQL. Если бы не повсеместная тяга бизнес-кошельков к созданию своих диалектов SQL, можно было бы написать вполне неплохой портируемый язык. А так он превращается в очередной набор бессмысленных заклинаний, каждое из которых будет интерпретировано платформой (причем одного и того же производителя) по-своему.

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

И, наконец, ну какое же это счастье -- писать на голом SQL? И это с размерами сегодняшних баз и нынешними задачами по обработке данных? Это все равно что сегодня писать программы на Basic 80-х годов: вроде как и Print есть, и циклы как бы в наличии, а развернуться негде.

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

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

Dark Night, Тем больше я с вами общаюсь, тем более убеждаюсь, что в БД вы, мягко говоря, не очень. На реляционных БД всё оптимизировано для максимальной производительности доступа к данным. И в этом случае простые запросы - самое оно. Если вам мало, берите ОРМ и пользуйтесь, там функционал - закачаешься, но на производительность тогда не жалуйтесь ))) ОРМ такие запросы генерирует порой, что волосы дыбом встают.

Все зависит от задачи. Я видела немало реализаций, где реляционная СУБД была подключена потому, что: а) все так делают; б) так работает быстрее; в) а какие еще бывают? г) у нас нет других разработчиков; д) да какая разница. А бизнес-логику делать на SQL -- это должна быть достаточно примитивная логика, которая, например, может быть реализована на уровне хранимых процедур. Можно, конечно. Но далеко не всегда.

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

Если хотите пример, где от реляционной БД остаются рожки да ножки -- пожалуйста: текстовые запросы пользователей. Скажем, Яндекс (немаленькая такая организация, не с одним лишь неттопом на обработке данных) пользуется нереляционной базой данных для обработки и хранения сведений запросов, построения портретов пользователей, назначения контекстной рекламы.

Dark Night, Насчёт примитивной логики. Спасибо, смешно. Это только лишний раз говорит о вашей некомпетентности в БД. Всё что можно реализовать на сервере приложений можно реализовать и на БД в хранимых процедурах. Только в разы быстрее работать будет. Я работал достаточно долго как фулстэк и могу сравнивать вполне компетентно.
А по текстовому поиску, то тот же ПГ по неявным совпадениям по триграммам работает не медленнее того же эластика например. Только мало кто об этом знает.
Я же в основном говорю о тяжёлых высоконагруженных приложениях для корпоративного учёта. Ту пока альтернативы реляционным БД просто нет.

Сергей, есть предложение сбавить тон. У меня нет желания превращать тему непонятно во что. Если обсуждаем, то обсуждаем. Если хочется добавить эмоций, это не ко мне, у меня на это времени нет. Работы хватает.

Миллион раз про самые разные системы слышала о том, что "на этом языке можно реализовать всё". Ну, реализуйте обход сильно разветвленного графа, например, средствами хранимых процедур. Или обеспечьте матмоделирование движения объектов в реальном времени. Кстати, за счет чего будет быстрее работать? Что сервер мощнее рабочей станции? Так в этом случае и не один запрос будет, а тысяча, например. Со всех рабочих станций одновременно. И это преимущество по мощности мгновенно становится недостатком.

Не вопрос, пусть Оракл смеется. Но Вам бы стоит читать мои сообщения внимательнее. Обработка изображений и геоданных (а также аудио- и видеоданных и многого другого) обеспечивается не собственно SQL-технологией, а дополнительными специальными расширениями, например, ArcGIS, где работает совсем другая платформа, а SQL ей нужен как пятому колесу нога, обеспечивая транспорт "запрос-табличный ответ", и никоим образом не участвуя в расчете результата.

Что касается профессионалов, то они нужны везде. И если Вам когда-нибудь захочется реализовать тот же граф или дерево на SQL-технологии, то после долгих мытарств Вы ее проклянете. Не вопрос, есть расширения типа Graph. Но у них есть и ограничения. И как только Вы упираетесь в ограничения, то Вам придется переписывать все своими руками.

Dark Night, Ещё раз. SQL и вообще реляционные СУБД предназначены для быстрого поиска и обработки структурированных связанных данных. Да это не везде применимо. Но в корпоративных системах учёта ,которых на рынке более 50 процентов от всех программных систем, они просто незаменимы. Я работаю именно на этом рынке. Если вы работаете на другом, то это не повод обвинять реляционные СУБД и SQL во всех грехах. Всему своё место. Просто не надо обобщать. Кстати в тех же колончатых БД используется по сути тот же самый SQL, хотя область применения таковых вообще другая. Переписывать не надо. )) Надо сразу выбирать наиболее подходящий инструментарий. )) Вот для этого и нужны профессионалы и желательно широкого профиля.

Для большинства систем учета -- согласна. И в голову не приходило в чем-то обвинять SQL, это хороший инструмент, но со своей областью применения, которую часто приходится неспецифически расширять.

Кстати, вопрос как к специалисту. Как в современных системах решается вопрос хранения несбалансированных древовидных структур? Простые примеры -- дерево товаров, дерево клиентов, дерево сотрудников. Не просто сохранить через ссылки "сами на себя", а иметь возможность эффективным SQL-запросом получать доступ к любой ветви или любому листу дерева. Не выходя за рамки реляционных таблиц, т.е. "json в ячейке" или "xml в ячейке" не подходит.

Dark Night, есть специальные инструменты для хранения графов, но с ними близко не сталкивался. В подобных инструментах обычно всё хорошо, если не приходится изменять что-то в середине дерева. То есть, если это системы просто накапливающие информацию, но без изменения уже существующей. В общем нет в жизни абсолютного счастья. ))) А для изменяемых данных и по быстрому поиску в них самое то колончатые БД. Но там уже никаких процедур внутри БД. Вообще. Только запросы.