> Раз уж вы спросили. Я двадцать лет (точнее, уже чуть больше) с Ораклом работаю. Я и есть тот самый DBA (сертифицированный, если что), о котором вы тут разглагольствуете.Чувствую меня хотят авторитетом задавить. Ок, я то не DBA и не претендую на истину в последней инстанции.
> Работаю с клиентами по всему миру.
Я еще студентом работал с клиентами по всему миру, собственно только на студентов такие вещи и срабатывают.
> У Оракла, если денег не жалко, есть специальные инструментальные средства
Соре, проприетарщина не нужна.
> А вообще все оптимизации запросов сводятся к выяснению количества записей в той или иной таблице, распределению данных в полях (сколько уникальных значений, а сколько повторяющихся) и способу соединения таблиц. Для упрощения работы СУБД предлагает пользователю план запросов, чтобы он понимал, куда копать дальше. В общем, ничего сложного, от слова совсем. Кто хоть сколь-либо плотно работает с запросами каждый день, и у кого голова на плечах (а не в облаках) - очень быстро способен разобраться, что да как.
Также просто как нарисовать сову. Если бы эти вещи были также просты как например настроить крон, то не было бы ни DBA, ни художников, а были бы просто "разработчик который сегодня настраивает базу" и "маляр который между покраской забора нарисует Мону Лизу".
> Вот зачем вы свой не особо успешный опыт проецируете на всех?
Что видел то и пишу. Из моего опыта у 100% людей были проблемы с sql и они встречаются вплоть до опытных разработчиков. Рад за вас если у 100% вашего окружения нет никаких проблем с РБД (и даже если они есть но вы про эти проблемы не знаете).
>Убедительности вашим словам это не добавляет. Просто признайте, что у вас нет таланта к этому занятию (программированию) в целом, и языку в частности. Не ваше это призвание. Это нормально, и ничего обидного здесь нет.
Перепрофилироваться в гадалку у вас явно не получится, тут вы совсем не убедительны.
> SQL - непроцедурный язык. PL/SQL - процедурный. Оба инструмента хорошо дополняют друг друга.
Мы сделаем язык специально для управления данными, стандартизируем его чтобы всем было хорошо, но управлять данными не очень то получается не очень, так что сделаем еще один язык (диалект?). Получается как в ералаше "но чалма не действует вот без этой штуки".
> Непереносимые решения создают, потому что вендор хочет привязать вас к своему продукту.
Я слышу эту параною с нулевых и она в основном беспочвенна. Если допустить что это правда, вендору гораздо проще отойти от SQL (например аменить одни токены на другие, вместо SELECT заставить писать GET например). Или продолжить использовать свой язык (вроде QUEL). Но этого не произошло.
Более того некоторые решения из одних баз потом становятся стандартом что мягко говоря не способствует привязыванию к продукту. А в контексте опенсурса где можно запросто сделать прокси-конвертер (что вы сами признаете) это и вовсе бессмысленно. Ответ напрашивается сам: их делают потому что стандарт (который напомню сделан специально для управления данными для БД) не покрывает необходимые возможности (о чем мы и сами пишите про PSQL).
Впрочем не удивалюсь если проприетарный оракл на самом деле так делает - у меня нет причин не доверять сертифицированному эксперту (и пользоваться ораклом и есть кактус).
> Поэтому если изначально подходить грамотно к архитектуре приложения, никаких нерешаемых принципиально проблем с переносом на другую более-менее развитую СУБД не будет.
"Хорошо делай - хорошо будет", спасибо, кэп. Скажу больше - никаких нерешаемых принципиально проблем никогда не будет (пока они не подходят к ограничениям физики), ведь это всего лишь байтики.
> Вы там про Питон упоминаете ниже. Неуж-то не слышали об SQL Alchemy? Вот это одно из таких решений.
Во многих наших питоновских сервисах используем.
> Если это комментарии в стиле "а вот тут колбаску заворачиваем", то и неудивительно.
Да, такое не редкость, но больше как резделитель между разными SQL запросами для разных блоков, что лично я считаю полезным.
> Уверен, у вас были бы ещё бОльшие проблемы, займись вы разбором какой-нибудь объектно-ориентированной библиотеки классов с тремя-четырьмя уровнями иерархии и множественным наследованием. SQL в этом плане намного проще и прозрачнее.
Внезапно с 4 уровнями иерархии в хорошо написанном коде обычно нет проблем с пониманием, особенно если ЯП под ООП заточен.
> Для того, чтобы с SQL дружить, надо хоть немного алгебру реляционных отношений знать. Также необходимо понимать, что такое множества, какие операции с ними возможны. Ещё важно знать структуру данных, с которыми вы работаете: какие функциональные зависимости между таблицами, как они нормализованы, какая кардинальность у полей.
Вот именно, чтобы управлять данными приходится схему держать в голове или рисовать самим или надеяться что базу проектировали правильно и напихали во всех необходимых местах constraint с check'ами и тогда просто распутывать эти ограничения пока ошибки не прекратятся. Где-то это и полезно, но нередко лишние (например большинство этих проверок итак сделало приложение получив данные от пользователя и два раза проверять смысла нет).
> Это то же самое, что для обычного программиста знать алгоритмы и структуры данных. Базовые знания, то есть, для работы с реляционными СУБД.
Только если сильных связей между полями структур будет столько же как между полями таблиц, я выкину этот код нераздумывая. А реляционные базы как будто бы специально сделаны чтобы всем этим зоопарком управлять, но почему мне приходится держать их в голове и распутывать вручную зависимости, я не понимаю.
> Вот тут вы честны, и это правильно, это хорошо. Лично вам - вполне возможно. Вы, вероятно, изначально плохо в языке разобрались, поэтому и барахтаетесь теперь в несистемных обрывках знаний.
Лично мне, большинству моих коллег, большинству моих коллег на прошлой работе, стажерам, бывшим одногруппникам (некоторые из которых сделали проектирование БД своей дипломной работой что лишний раз подтверждает что это не дело на 5 минут).
> В итоге занимаетесь г-нокодингом.
Именно так я себя чувствую когда пишу на SQL какой-нибудь сложный запрос. Можно было бы предположить что я плохой танцор, но это не объясняет почему остальные (кроме DBA и опытных разработчиков) чувствуют себя также.
> Если ваши таблицы сколь-либо большие, с таким подходом, как ваш, вы напрочь убиваете возможность оптимизировать ваши запросы средствами СУБД. Эффективность оптимизатора здесь будет стремиться к нулю.
Да, я это понимаю и принимаю. Но как правило это экономит мое время (хотя казалось бы должно быть наоборот), я избегаю магию оптимизатора и уверен что добавление еще одного поля магическим образом не увеличит время выполнения в 10 раз (что неоднократно случалось). А то как я обрабатываю данные, мной контролируется. Я могу просто писать код привычным для себя образом не утруждая себя запоминанием волшебных оптимизаций для конкретных БД (которые возможно перестанут быть актуальны в следующем релизе БД, еще один камень в копилку "универсального" стандарта SQL). Справедливости ради замечу что мои десятки запросов очевидно менее эффективны в контексте нагрузки на базу чем один грамотно подготовленный мегазапрос, но учитывая количество остальных запросы и то что мои запросы не носят периодический характер, это капля в море, а времени мне экономит изрядно.
> Потому что кардинальность ваших таблиц может со временем измениться, и ваши скрипты придётся переписывать по новой, беря в учёт изменившуюся реальность.
Как раз нет. По-моему способу когда я делаю множество простых запросов в (основном) одну таблицу, связи между таблицами меня меньше всего интересуют.
