Какая часть знаний RDBMS независима от конкретной СУБД?
Вот есть же стандарт языка SQL. Актуальная версия SQL:2016 даже включает в себя SQL/JSON, например.
Почему мы в принципе разделяем опыт разработчиков БД по самой СУБД?
Предполагаю, дело в знании подкапотки. Мало знать декларативный язык, стоит знать детали императивной реализации запроса базой данных. То, как БД будет работать с вашими данными и с вашими запросами к ним.
MS SQL, OracleDb, PostgreSQL, MySQL, — у каждой БД под капотом свой движок. Некоторые даже могут использовать разные движки для разных таблиц в одной схеме. Это приводит к разным алгоритмам обработки. И разным артефактам этой самой обработки.
Да, не всегда всё идет по плану. И тогда крутые DBD вместе с DBA начинают "дебажить" базу данных. Пытаться подкрутить её так, чтобы она работала "как надо". Прибить нужный план запроса хинтами, поменять настройки самой СУБД типа размера той или иной области памяти.
Здесь начинают работать знания специфичные для базы данных. Такие знания не всегда можно нагуглить "по ходу". Им нужно учиться у опытных коллег. Этим постом я хочу отдать должное коллеге, у которого я многому научился. Еще до удалёнки, Денис Кивилев вёл очные курсы внутри QIWI.
Денис ведет канал Oracle Developer. Многие знания релевантны для любой СУБД. В вебинаре про PostgreSQL, рассказывая об индексах и о партиционировании, я во многом опирался на знания, которые мне дал Денис. При этом у Oracle есть огромная специфика по части PL/SQL и по части внутреннего устройства. Денис подробно рассказывает и об общих темах, и о специфике Oracle. Советую подписаться.
Вот есть же стандарт языка SQL. Актуальная версия SQL:2016 даже включает в себя SQL/JSON, например.
Почему мы в принципе разделяем опыт разработчиков БД по самой СУБД?
Предполагаю, дело в знании подкапотки. Мало знать декларативный язык, стоит знать детали императивной реализации запроса базой данных. То, как БД будет работать с вашими данными и с вашими запросами к ним.
MS SQL, OracleDb, PostgreSQL, MySQL, — у каждой БД под капотом свой движок. Некоторые даже могут использовать разные движки для разных таблиц в одной схеме. Это приводит к разным алгоритмам обработки. И разным артефактам этой самой обработки.
Да, не всегда всё идет по плану. И тогда крутые DBD вместе с DBA начинают "дебажить" базу данных. Пытаться подкрутить её так, чтобы она работала "как надо". Прибить нужный план запроса хинтами, поменять настройки самой СУБД типа размера той или иной области памяти.
Здесь начинают работать знания специфичные для базы данных. Такие знания не всегда можно нагуглить "по ходу". Им нужно учиться у опытных коллег. Этим постом я хочу отдать должное коллеге, у которого я многому научился. Еще до удалёнки, Денис Кивилев вёл очные курсы внутри QIWI.
Денис ведет канал Oracle Developer. Многие знания релевантны для любой СУБД. В вебинаре про PostgreSQL, рассказывая об индексах и о партиционировании, я во многом опирался на знания, которые мне дал Денис. При этом у Oracle есть огромная специфика по части PL/SQL и по части внутреннего устройства. Денис подробно рассказывает и об общих темах, и о специфике Oracle. Советую подписаться.