Sergey Brazhkin будет жить. Поприветствуем!

Datepart тебе нужен или Month(date) and YEAR(date) или CAST(date as date) BETWEEN '2018-09-01' and '2018-09-30'

еще такой вариант нашел: EXTRACT(MONTH FROM date)

ну это что-то не из MS SQL

ну это что-то не из MS SQL

да, PostgreSQL и MySQL

всем привет) такой вопрос, создаю резюме на позицию SQL developer, такие навыки адекватно написать или лучше что-то убрать/добавить? в требованиях к вакансии только sql - C++ - SQL - JavaScript (AngularJS, jQuery) - OOP, GoF - Operating System (Windows. Linux) или лучше убрать все и расписать подробнее знания только в сфере sql? P.S извините, если не тот чат

всем привет) такой вопрос, создаю резюме на позицию SQL developer, такие навыки адекватно написать или лучше что-то убрать/добавить? в требованиях к вакансии только sql - C++ - SQL - JavaScript (AngularJS, jQuery) - OOP, GoF - Operating System (Windows. Linux) или лучше убрать все и расписать подробнее знания только в сфере sql? P.S извините, если не тот чат

а ты все это знаешь или слышал про такие названия ? ну как знаешь, используешь и т.д.

а ты все это знаешь или слышал про такие названия ? ну как знаешь, используешь и т.д.

я всё это знаю, с плюсами работала 2 года, с остальным меньше просто насколько нужно это указывать, если в требованиях нет языков программирования? хочется максимально читабельное и содержательное, относительно вакансии, резюме

никогда не шла на позицию чисто sql, поэтому не до конца понимаю, что там нужно hr-ам)

Храм, ничего. Они скуель не знают.

Храм, ничего. Они скуель не знают.

а рекрутерам?

я всё это знаю, с плюсами работала 2 года, с остальным меньше просто насколько нужно это указывать, если в требованиях нет языков программирования? хочется максимально читабельное и содержательное, относительно вакансии, резюме

в дополнительной секции "подкиньте побольше зп, пушо <список>"

указать надо, подробно расписывать нет - на собесе спросят

в дополнительной секции "подкиньте побольше зп, пушо <список>"

что такое пушо?)) т.е хватит просто "SQL" или написать "OLAP, триггеры, функции.." и т.д?

Я хз что там в основной писать, но все дополнительные скиллы совершенно точно стоит указывать в отдельной секции. Типа "вас также может заинтересовать..." и список, потому что во-первых это лучше показывает человека и насколько он готов смотреть вне рамок текущих задач, во-вторых может там есть пересечение, которое в вакансии не указали, потому что на "sql с базовыми умениями плюсов" не придет вообще никто.

Я хз что там в основной писать, но все дополнительные скиллы совершенно точно стоит указывать в отдельной секции. Типа "вас также может заинтересовать..." и список, потому что во-первых это лучше показывает человека и насколько он готов смотреть вне рамок текущих задач, во-вторых может там есть пересечение, которое в вакансии не указали, потому что на "sql с базовыми умениями плюсов" не придет вообще никто.

Спасибо большое)

Ребята, а как вы к ORM относитесь? Не писать же сырые запросы везде

ща начнется

тупые разрабы, используют орм и ничего не понимают

рушат наши прекрасные бд

+1

Ребятушки, чем щас модно мускул балансить?

Я не буду учить твой Garbage Query Language https://habr.com/post/422667/

Я не буду учить твой Garbage Query Language https://habr.com/post/422667/

Жизненно ;-(

Я не буду учить твой Garbage Query Language https://habr.com/post/422667/

жыза

Я не буду учить твой Garbage Query Language https://habr.com/post/422667/

че там, опять операторы шаблонизатора выебываются?

И так там у них всё. Через жопу.

А нормальный ресурс есть?

Я таких не знаю.

Только дока, только хардкор?))

Я не буду учить твой Garbage Query Language https://habr.com/post/422667/

> Каждый SaaS-продукт должен предоставлять возможность скопировать все данные в мою собственную SQL БД (в моем случае Postgresql/Redshift) АААААААААААААА АХАХАХХАХАХ ХАААААААААХАХХАХАХ АХАХАХАХАХХАХАХАХА

> Необходим 30-летний мораторий на изобретение новых языков запросов. я боюсь следующую строчку читать, если они так быстро эскалируют ситуацию

> Кроме того, каждая база данных, также старается заново изобрести язык запросов. У Mongo есть свой ужасный язык запросов, который я никогда не понимал, у Lucene свой и т.д. как же так получилось ???

может ли быть такое, что в мире существуют модели, не подходящие под SQL ???

блядь, там еще по серьезу в комментариях обсужадют

хабр тот

Типичная хабропомойка, считаемся с мнением афторов

Ну монгу он зря ругает. Монга то документы с иерархией хранит. И разбирать многоуровневый JSON через SQL не удачная идея

Ну монгу он зря ругает. Монга то документы с иерархией хранит. И разбирать многоуровневый JSON через SQL не удачная идея

Почему неудачная?

действительно, почему ????????????

Почему неудачная?

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

nyet, все на свете должно запихиваться в двумерные матрицы

Как альтернатива - GraphQL для документов, но не SQL.

на хабре хуйни не напишут!

nyet, все на свете должно запихиваться в двумерные матрицы

Вот этого плюсую

если у вас не запихнулось в двумерную матрицу, значит вы плохо подошли к архитектуре!

нужно переписывать проект заново!

Нужно ресерчить в коворкинге перед этим

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

В случае если надо тупо как-то примитивно изменить дерево то да, а в остальных случаях надо смотреть.

В случае если надо тупо как-то примитивно изменить дерево то да, а в остальных случаях надо смотреть.

джойн по седьмому элементу массива это же элементарно как его решить

джойн по седьмому элементу массива это же элементарно как его решить

Это вызывает у тебя сложности? :)

джойн по седьмому элементу массива это же элементарно как его решить

Так, серьезные вещи обсуждаем. Не троль тут

Та же постгресина, например, хорошо работает с json.

Это вызывает у тебя сложности? :)

http://lurkmore.to/%D0%9A%D0%BE%D0%BF%D0%B8%D0%BF%D0%B0%D1%81%D1%82%D0%B0:%D0%A8indows

Та же постгресина, например, хорошо работает с json.

MySQL тоже работает. Но все равно я прохожу конвертацию JSON -> таблица -> JSON (отдаю на фронтенд).

MySQL тоже работает. Но все равно я прохожу конвертацию JSON -> таблица -> JSON (отдаю на фронтенд).

#проклято

MySQL тоже работает. Но все равно я прохожу конвертацию JSON -> таблица -> JSON (отдаю на фронтенд).

так храни json в таблице как json

И сразу его выдавай, не конверть

так храни json в таблице как json

#бипроклято

ждем еще людей, которые построили на этом graphql, для тернарного проклятия

ах так это ж убер #треклято

а шо убер?

не шмогли сделать носкл поверх поштгреса

поэтому сделали его поверх мушкула

абстракций лишних не бывает

поэтому сделали его поверх мушкула

Ого, месье знают толк в извращениях.

И сразу его выдавай, не конверть

Это если мне в сыром виде нужно отдать. Я если выбрать что-то? Например мне надо суммы с детализацией сделать и с суммами по позиции (это реальный кейс). Делаю несколько выборок разной уровни детализации и склеиваю их в один ответ.

ERROR: S client not available

ждем еще людей, которые построили на этом graphql, для тернарного проклятия

А я просто граф построил в кассандре :)

Это если мне в сыром виде нужно отдать. Я если выбрать что-то? Например мне надо суммы с детализацией сделать и с суммами по позиции (это реальный кейс). Делаю несколько выборок разной уровни детализации и склеиваю их в один ответ.

Ну например постгресина прекрасно подходит для этого, если ты конешн сумеешь осилить sql

Хранишь список с json, делаешь индексы по json, делаешь сложные запросы и агрегации из json.

Хранишь список с json, делаешь индексы по json, делаешь сложные запросы и агрегации из json.

Но не знаешь зачем?

Хранишь список с json, делаешь индексы по json, делаешь сложные запросы и агрегации из json.

Ну и получаю прямоугольные таблицы. Которую снова склеиваю в JSON. Лишний шаг

Ну и получаю прямоугольные таблицы. Которую снова склеиваю в JSON. Лишний шаг

Дались тебе таблицы, делай запрос который возьмёт json и выдаст json.

ах так это ж убер #треклято

Чет поддержу тебя пожалуй. Они какие то того

Но не знаешь зачем?

Думаешь?

Думаешь?

Always

Always

Но не знаешь зачем?

Дай пример? Например у меня таблица с JSON постов, и массивом коментариев в них. Как будет выглядеть запрос который выдаст все посты и коментарии в них, но только за вчера отсортированные по дате?

Дай пример? Например у меня таблица с JSON постов, и массивом коментариев в них. Как будет выглядеть запрос который выдаст все посты и коментарии в них, но только за вчера отсортированные по дате?

Ты sql умеешь? Функции постгреса по json изучал? :)

Ребята, пока тут актив, вы всё таки скажите пожалуйста что думаете про ОРМки

Я как раз на MySQL работаю. Вдруг и перейду на постгресс если мне поможешь. У меня таких отчетов куча как я описал.

Ребята, пока тут актив, вы всё таки скажите пожалуйста что думаете про ОРМки

Подходят только для общих случаев. Нестандартные задачи превращают в ад.

Я как раз на MySQL работаю. Вдруг и перейду на постгресс если мне поможешь. У меня таких отчетов куча как я описал.

Ок

Подходят только для общих случаев. Нестандартные задачи превращают в ад.

Типа всяких запросов на n минут?

Ок

И количество JOIN запредельное чтобы это все собрать. А по факту это write only документы с своей структурой. Вот и посматриваю на монги и прочее что может мне от JOIN исбавится и работать с структурой запрямую

И количество JOIN запредельное чтобы это все собрать. А по факту это write only документы с своей структурой. Вот и посматриваю на монги и прочее что может мне от JOIN исбавится и работать с структурой запрямую

В мускуле да, с join проблема.

Я бы не строил ничего сложного на Мускуле даже за деньги.

И количество JOIN запредельное чтобы это все собрать. А по факту это write only документы с своей структурой. Вот и посматриваю на монги и прочее что может мне от JOIN исбавится и работать с структурой запрямую

Да, тут я согласен, носкл для этого очень хорошо подходит, зачем городить ебалу в реляционке

Типа всяких запросов на n минут?

Блог, форум и т.д. А на больших данных может производительность попортить значительно. Потому что на чистом SQL можно построить запрос по своим индексам, а ORM сам решает как выполнять и заставить его сложно следовать своей схеме. Я сталкивался с Hibernate

Но не знаешь зачем?

Я то как раз знаю. Но вот зачем в реляционки совать json? Насколько я понимаю так это для совсем тупых, которые в sql не могут нормально.

Я бы не строил ничего сложного на Мускуле даже за деньги.

Он хорош и стабилен. Но жутко кривой при обновлении схемы. Может повесить систему на несколько часов из за того что пересоздает таблицы. Поэтому мы на реплике это делаем.

Я то как раз знаю. Но вот зачем в реляционки совать json? Насколько я понимаю так это для совсем тупых, которые в sql не могут нормально.

А в чём проблема в реаляционке хранить json?

Зачем городить огород из Мускула+Монга когда можно взять тот же Постгрес?

Он хорош и стабилен. Но жутко кривой при обновлении схемы. Может повесить систему на несколько часов из за того что пересоздает таблицы. Поэтому мы на реплике это делаем.

Просто ты ещё не понял что такое например Постгресина. Когда пощупаешь постгресину, то забудешь Мускул как страшный сон.

Зачем городить огород из Мускула+Монга когда можно взять тот же Постгрес?

Это нормальная практика.

Постгресс как и все реляционки делает плоскую таблицу в ответ и по другому не может. Он на это заточен.

Монга намного удобнее для хранения документов