А причем тут Spark SQL? Если знать что под капотом творится, какая разница на чем писать? А если не знаешь, то и на Python/Scala хрень можно написать. Что за высокомерие?
Тем более что SQL более понятен аналитикам, бизнесу его дешевле поддерживать, поэтому я чаще всего на проектах слышу от бизнеса требование код писать на SQL. В 99% случаев можно спокойно им обойтись. А для остальных редких случаев можно почитать spark internals, либо в исходники залезть.
Что от статьи, что от первых комментариев несёт каким-то высокомерием и пижонством, особенно про собеседования. Все вокруг тупые, один вы Д'артаньян
Небольшое замечание: собираете результаты с помощью функции toPandas() может быть конкретно вы в вашем случае, но это далеко не самая широко используемая функция. Это ещё pandas должен быть установлен. По умолчанию используется родная функция collect()
Какой-то странный довод для аргументации архитектуры системы/хранилища. Может разработчик всё-таки не будет что-то там делать "на глаз", "на память" и т.д. и т.п. Или может он просто хреновый разработчик?
Если даже с помощью гугла, вы не можете написать хранимую процедуру, а вместо этого, целую неделю отдельный человек пишет её вам, возможно, разработка это не для вас, и ваше место за плитой во «Вкусно и точка».
Если все, что вы умеете, это писать хранимые процедуры и добавлять таблицу в базу, то у меня тоже плохая новость. Ваша профессия - сисадмин, в лучшем случае. В связи с этим, возможно, вам стоит пересмотреть свои зарплатные ожидания.
С самого начала статья выглядела как попытка выпендриться в незнакомой области, в которой похоже автор вообще не разбирается, а после этого абзаца вообще всё стало ясно. Видимо в представлении автора программисты баз данных только пишут хранимую процедуру и добавляют табличку в базу. Видел я поделки таких "спецов".
Надеюсь операцию на сердце вам тоже сделает хирург-проктолог, с Гуглом наперевес. Иначе ему место во вкусно и точка.
Да, давайте расскажите нам о способах оптимизации запроса для SQLite на таблице из 5 строк. Оптимизация запросов на сферических в вакууме примерах абсолютно бесполезный труд.
Мое мнение - оптимизацией запроса нужно заниматься когда это действительно нужно. Это зависит от множества факторов таких как: конкретная СУБД, конкретные данные, модель данных, индексы, паралеллизм, оптимизатор в субд, план запроса и т.д. и т.п. А до тех пор пока такой задачи не стоит - а у нас тут нет ничего, только задачка в вакууме - нужно писать как можно проще и понятнее.
Right join - абсолютно бесполезная вещь, которая только сбивает с толку. Нет такого right join который бы нельзя было бы заменить на left join. Поэтому принято использовать left join - он более интуитивно понятен. Погуглите различные "SQL style guide" от топовых компаний, в них зачастую вообще явный запрет на использование right join.
В 3.1. я бы не стал использовать подзапрос и right join. Писать rigth join - вообще плохой тон. Это решается проще и читается легче:
select c.name as contractor, sum(op.summa) as summa
from operation op
left join contractor c on c.id_contr = op.id_contr
group by c.name
order by 1 nulls last
Тут англоязычных то ресурсов мало, а вы хотите на русском. На английском рекомендую аналог leetcode только для SQL: https://www.stratascratch.com/
И советую сразу учиться форматировать SQL-код, если уж вы выносите их на всеобщее обозрение - ваши запросы плохо читаются.
Сейчас в самом простом блокноте есть плагины и подсветка синтаксиса. Я сам пишу SQL в SublimeText. И мне тоже не нужны монструозные IDE для этого. Так что это такой себе аргумент.
Объясните мне, зачем в 21 веке, когда есть миллион разных IDE, которые умеют подсвечивать SQL-код, писать служебные слова в Upper-case? Я помню так писали, когда не было нормальных IDE. Но сейчас то зачем??? Когда я вижу такой код, мне сразу вспоминается мой 386 комп и BASIC.
Я сам не люблю договоров с оговорками и мелким шрифтом, но вот тут вы преувеличиваете. При любом случае перед списанием выводится экран с подробным описанием тарифа и там четко написано, что километраж оплачивается отдельно. Никакого мелкого шрифта там нет. Прямо сейчас проверил.
Я уверен, что вы и договор полностью не читали при регистрации, просто подмахнули не глядя, как многие это делают. А зря.
З.Ы. В яндексе не работаю и никак с ними не связан. Просто давно пользуюсь разными каршерингами и внимательно читаю, прежде чем жать бездумно все кнопки.
Исправьте заголовок — это советы только для СУБД Postgres. Либо пишите реальные советы, применимые для всех. А то слишком громкий заголовок, а пользы никакой для тех кто не работает с Postgres
Удивительно, но мой первый смартфон, который я заказал из Китая (лет эдак 10 назад), был с такой функцией! Раньше все китайские смартфоны были с TV-тюнерами, потом китайцы перестали пихать их во все смартфоны. А здесь ASUS видимо решили вспомнить?
А причем тут Spark SQL? Если знать что под капотом творится, какая разница на чем писать? А если не знаешь, то и на Python/Scala хрень можно написать. Что за высокомерие?
Тем более что SQL более понятен аналитикам, бизнесу его дешевле поддерживать, поэтому я чаще всего на проектах слышу от бизнеса требование код писать на SQL. В 99% случаев можно спокойно им обойтись. А для остальных редких случаев можно почитать spark internals, либо в исходники залезть.
Что от статьи, что от первых комментариев несёт каким-то высокомерием и пижонством, особенно про собеседования. Все вокруг тупые, один вы Д'артаньян
Небольшое замечание: собираете результаты с помощью функции toPandas() может быть конкретно вы в вашем случае, но это далеко не самая широко используемая функция. Это ещё pandas должен быть установлен. По умолчанию используется родная функция collect()
Вы назвали Apache Spark узкоспециализированным навыком, востребованным только в считанных компаниях или я ошибаюсь?
Какой-то странный довод для аргументации архитектуры системы/хранилища. Может разработчик всё-таки не будет что-то там делать "на глаз", "на память" и т.д. и т.п. Или может он просто хреновый разработчик?
Под windows пока лучше чем связка Conemu + Far не нашёл
Сейчас бы судить об экономике по производству вооружения. То что людям жрать нечего - это ерунда, главное что снарядов много.
С самого начала статья выглядела как попытка выпендриться в незнакомой области, в которой похоже автор вообще не разбирается, а после этого абзаца вообще всё стало ясно. Видимо в представлении автора программисты баз данных только пишут хранимую процедуру и добавляют табличку в базу. Видел я поделки таких "спецов".
Надеюсь операцию на сердце вам тоже сделает хирург-проктолог, с Гуглом наперевес. Иначе ему место во вкусно и точка.
Да, давайте расскажите нам о способах оптимизации запроса для SQLite на таблице из 5 строк. Оптимизация запросов на сферических в вакууме примерах абсолютно бесполезный труд.
Планы где? В какой СУБД и на какой версии? На каких данных? В задачах не указано ничего кроме условия задачи. Какой может быть план?
Мое мнение - оптимизацией запроса нужно заниматься когда это действительно нужно. Это зависит от множества факторов таких как: конкретная СУБД, конкретные данные, модель данных, индексы, паралеллизм, оптимизатор в субд, план запроса и т.д. и т.п. А до тех пор пока такой задачи не стоит - а у нас тут нет ничего, только задачка в вакууме - нужно писать как можно проще и понятнее.
Right join - абсолютно бесполезная вещь, которая только сбивает с толку. Нет такого right join который бы нельзя было бы заменить на left join. Поэтому принято использовать left join - он более интуитивно понятен. Погуглите различные "SQL style guide" от топовых компаний, в них зачастую вообще явный запрет на использование right join.
В 3.1. я бы не стал использовать подзапрос и right join. Писать rigth join - вообще плохой тон. Это решается проще и читается легче:
Тут англоязычных то ресурсов мало, а вы хотите на русском. На английском рекомендую аналог leetcode только для SQL: https://www.stratascratch.com/
И советую сразу учиться форматировать SQL-код, если уж вы выносите их на всеобщее обозрение - ваши запросы плохо читаются.
Константы != Служебные слова.
Второе встречается гораздо чаще.
Напомните, в каком языке до сих пор принято писать служебные слова в верхнем регистре?
Сейчас в самом простом блокноте есть плагины и подсветка синтаксиса. Я сам пишу SQL в SublimeText. И мне тоже не нужны монструозные IDE для этого. Так что это такой себе аргумент.
Мой вопрос был к тем, кто аргументирует это так, цитирую: "чтобы служебные слова сразу бросались в глаза".
В других языках давно от такого отошли, с развитием IDE.
Никто конечно вам не запрещает, если так нравится.
Как по мне - это неудобно и некрасиво.
Объясните мне, зачем в 21 веке, когда есть миллион разных IDE, которые умеют подсвечивать SQL-код, писать служебные слова в Upper-case? Я помню так писали, когда не было нормальных IDE. Но сейчас то зачем??? Когда я вижу такой код, мне сразу вспоминается мой 386 комп и BASIC.
Я уверен, что вы и договор полностью не читали при регистрации, просто подмахнули не глядя, как многие это делают. А зря.
З.Ы. В яндексе не работаю и никак с ними не связан. Просто давно пользуюсь разными каршерингами и внимательно читаю, прежде чем жать бездумно все кнопки.
Исправьте заголовок — это советы только для СУБД Postgres. Либо пишите реальные советы, применимые для всех. А то слишком громкий заголовок, а пользы никакой для тех кто не работает с Postgres