Туториалы:
- https://www.postgresqltutorial.com/
- https://www.sqlitetutorial.net/
- https://www.oracletutorial.com/
- https://www.mysqltutorial.org/
Задачи:
- https://www.sql-ex.ru
- https://www.codewars.com/?language=sql
Инструменты проектирования БД
- Визуализация планов запросов PostgreSQL: https://explain.dalibo.com/
- GUI-клиент для работы с БД: https://dbeaver.io/
Видосики:
- Плейлисты по разным СУБД: https://www.youtube.com/c/SQLDeveloperBI/playlists
- https://www.youtube.com/playlist?list=PLY7PmJJFH5nT-lbFKxfbp3rw5BBuq5Azo
Литература:
- Томас Кайт. Oracle для профессионалов
- https://postgrespro.ru/education/books/dbtech
- Алан Бьюли. Изучаем SQL. - про MySQL
- К. Дж. Дейт. Введение в системы баз данных
- Database Systems: Design, Implementation, & Management (Carlos Coronel, Steven Morris)
Прочее:
- https://github.com/agarcialeon/awesome-database
- https://dbdb.io/
- https://db.cs.cmu.edu/
- https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA/playlists
- Сравнение диалектов SQL: http://troels.arvin.dk/db/rdbms/
- Как БД работают изнутри: https://habr.com/ru/company/mailru/blog/266811/
Ссылки для альтернативно мыслящих:
- https://www.w3schools.com/sql/
- https://learnxinyminutes.com/docs/sql/
- https://metanit.com/sql/
- http://sql-tutorial.ru/
- https://metanit.com/nosql/mongodb/
- https://www.mysqltutorial.org/mysql-resources.aspx
- https://shlomi-noach.github.io/awesome-mysql/
- https://www.mysql.com/products/workbench/
FAQ:
Q: Нужно ли знать английский?
A: Нет.
Q: Что лучше, SQL или NoSQL?
A: SQL.
Q: Вопросы с лабами и задачками
A: Задавай, ответят, но могут и обоссать.
Q: Помогите с :ORM_нейм для :язык_нейм
A: Лучше спроси в тредах по конкретным языкам.
Q: Где хранить файлы?
A: Не в БД. Для этого есть объектные хранилища, такие как Amazon S3 и Ceph.
Q: Нужны ли сертификаты?
A: Только если собираешься заводить трактор.
Здесь мы:
- Разбираемся, почему PostgreSQL - не Oracle
- Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
- Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обеществе
- Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
- Анализируем, как работает поиск вконтакте
- И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно.
Поехали!
За 10 дней ни одного поста.
Ну я вкатуджон, я задавал вопросы и Вы меня выгнали с такой формулировкой мол читай зе факинг мануал, ну тогда сами постите, если мне рот затыкаете.
Мне этот пост >>3272255 → в шапку засунуть?
Да знаем мы твои "посты":
- Хочу вкатиться хуй пойми куда увидев рекламу говнокурсов
- Сделайте за меня задачу, условие которой надо угадать или выпытывать у меня пол треда
- Вот запрос на две страницы. Почему у васи хуй на лбу? Нет, стурктуры таблиц не будет. А... и я имел ввиду почему у лены пизда до колена. То есть почему у васи пизда на лбу до колена... Че вы доебались до мелочей, я конкретный вопрос задал.
В чем смысл на новый проект ставить mysql вместо постгри? Какие у нее вообще плюсы есть в сравнении?
Ну мне mysql больше понравился в плане "легковесности" если конечно локально ставить. Попроще в развертывании и не так загружает "железо".
>908 откликнулось
>10 смотрят
>45 тысяч до вычета налогов
>до вычета
Это пиздец.
Моя первая работа с базами данных была на компанию в регионах в 2017 году. Платили 30к гросс. Даже тогда я считал это рабством ебаный. Работа в коллекторском агентстве Сбера - дочерняя компания. Но я благодарен этому опыту, ибо я там делал отчётность и писал десятки запросов в день.
Тут же натурально работа только на еду. Даже на койко место + еду в ДС не хватит.
>>3390354
>>3390408
Слепошарые заводчане, это вечерняя подработка для профильных студней, которые хотят себе на карманные расходы подзаработать. Пицценосцам и курсожорам там один хуй ничего не светит.
А без "субъективно"? Я только слышал где-то мол mysql умеет как-то круто клатеризоваться
>но будут много платить.
раньше да, сейчас уже не так много и ебли в сто раз больше.
тебе точно в НИИ. сужу только потому, как ты сформулировал вопрос и основываясь на твоих сомнениях.
а вообще тут не правильного ответа, в обоих случаях свои плюсы и минсы. Пойти в НИИ не значит, что ты всю жизнь будешь за гроши чаи с кузьмичами гонять, так же как и банк далеко не всегда сулит брольшие горы.
если бы ты задал такой же вопрос лет 10-15 назад, когда я заканчивал ВУЗ. тогда точно бы банк.
Спасибо за ответ! Сам кем работаешь, анон, если не секрет?
C/C++/C# разраб
у меня есть опыт работы в банковской сфере (небольшой)
скипнул. да скорее всего я просто неудачно попал в неудачное время, но...
На собесе "Нам срочно надо, ряяя...похуй что это не знаешь, разберешся по ходу, время будет".
По факту уже на второй недели началось...
"Это короче бросай, потом доделаешь. тут крупный клиент, вот это надо сделать быстро, срок.."Ну за сегодня сможешь?"
никогда не забуду это состояние опустошения после работы.
когда тебя ебут по срокам, работа на выходных и вместо того, чтобы разобраться и сделать нормально, делаешь абы как лишь бы в тайминг уложиться.
> C/C++/C# разраб
Это круто, я тоже думаю подтянуть C/C++ в перспективе
> у меня есть опыт работы в банковской сфере (небольшой)
А сейчас в какой сфере работаешь?
> "Ну за сегодня сможешь?"
Вот тоже не нравится это. С первого курса не мог терпеть эту срочность. Хочется верить, что есть места где можно вдумчиво работать и разбираться в коде, а не скакать по верхам
>А сейчас в какой сфере работаешь?
C#/бэкенд
>вдумчиво работать и разбираться в коде, а не скакать по верхам
НИИ или opensource)
знания имею базовые, выше джоина пока не знаю, все, что показывали на обучении, выглядело как тонна бесполезной инфы, впадлу все это учить
и вот вопрос, а с помощью нейросети, которая, по моему мнению, может спокойно писать любой запрос, еще учитывая мою помощь с умением читать код: смогу ли я таким там свободно работать этим способом? или есть подводные? или может люди уже так и работают? или работодатель будет очень недоволен если увидит, что я черпаю помощь у ИИ? или всем поебать будет, главное делай работу
>лучших учеников заберут на работу.
>тонна бесполезной инфы, впадлу все это учить
>я черпаю помощь у ИИ
Ты уже не подходишь под определение лучшего ученика. Вообще скуль учится буквально за месяц, если не за недели две, по крайней мере на уровне аналитика. Напряги сраку и осиль ты этот простейший синтаксис.
а я под него и не планирую подходить, я не отличник/зубрила/ботан, чтобы всю эту хуйню выучивать, если я могу за пару секунд ответ получить, и мне и компании это в плюс, 2025 год уже
> sql аналитика
Чиво блядь? Писать скули может даже саппорт если припрёт, а учить тебя должны не скулю, а билять аналитике.
> всем поебать будет, главное делай работу
this. Только ценность аналитика не втом чтобы писать скули, а в том чтобы знать что писать и как интерпретировать результат. Удачи в начинании лох.
В этом и суть что sql отличает нормального аналитика от Мани-эксельщика который научился ВПРы делать.
АналИтики часто завязаны на предметную область. Банки, ритеил, риски, etc. А с умением в sql ты можешь быстро перекатиться из одной предметной области в другую.
А насколько быстро осуществляется вкат в предметную область? Реально самому обучиться? Например, для продуктовой аналитики нужно знать метрики, их вроде несложно выучить. А вот в банковской сфере надо знать дохрена, т.к. предметная область обширная.
Анрил узнать это вне работы. Только непосредственно на работе познаешь
Нашел 1 страницу просто с описанием и в книге больше нет никаких примеров как и в других книгах.
Что за пиздец? Когда их применяют? Какие юзкейсы?
Вот есть у тебя таблица с кучей путей к файлам. Ты хочешь их обработать. Берёшь и начинаешь в несколько потоков читать из таблицы. Появляется проблема - разные потоки могут выбрать из базы один и тот же файл и начать его пердолить. Это плохо и потому, что лишняя работа, и потому, что сами файлы тоже будут лочиться на диске. Решение - каждый поток, когда делает select из таблицы, блокирует эти строки. Тогда другие потоки их не получат, если будут делать select + skip locked. Проблема решена. Может быть другая проблема с неотпусканием блокировки, если процесс вдруг завис, например. Поэтому можно ещё мониторить и прибивать процессы, которые слишком долго работают.
Ты делаешь это неправильно. Надо просто разбить батч на части и каждому воркеру дать свое подмножество. Тогда и блокировки не потребуются.
Прочитать всю таблицу, разбить на батчи, запомнить какой батч кому дал и проконтролировать что он обработан. Короче написать целое приложение, которое таблицу на батчи делит.
И все это вместо двух процедур: getRowsForProcessing() и markRowsAsProcessed() . Вот уж внатуре - ебанутым нет покоя.
А потом железная женщина будит тебя в три утра, потому что твой сервис опять залочил бд и пошли пятисотые.
Какая женщина, ебанько? Блокировка на изменение строк вешается. "залочил бд" - что это вообще нахуй означает? У тебя, долбоеба, все транзакции блокировку вешают.
Каждый раз в ахуе с таких кретинов. Ну не понимает нихуя в теме, но надо высраться обязательно. Про каких-то женщин, про блокировку базы, хуйню малафью.
Потому что практические примеры познаются, как ни странно, на практике. Всех ситуаций не предугадаешь, самый простой и часто встречающийся пример - транзакция на списание денег со счёта.
Думай сам, включай фантазию.
https://vladmihalcea.com/race-condition/
Вот например, когда обосрались с изоляцией транзакций.
>Надо просто разбить батч на части
Как? Я сейчас так и делаю, беру по несколько строк (батч) и их блокирую. Если не блокировать строки, то надо отдельно мониторить, какие строки сейчас каким воркером обрабатываются.
Первым N строкам присваиваешь worker=1, следующим N строкам worker=2 и так далее. Каждый воркер знает свой номер, они уникальные, и селектит только строки со своим номером. Воркер обрабатывает только свои строки, никакой гонки, блокировка не нужна.
>Каждый воркер знает свой номер
Откуда? Есть пул свободных воркеров, они не знают ничего о других воркерах. Они работают независимо.
С блокировкой ты просто селектишь незалоченные строки, их лочишь и работаешь с ними. Транзакция либо завершается, если воркер отработал, или откатывается, если воркер почему-то помер. В любом случае лок снимается, и с этими строками можно опять работать (если прошлый воркер умер). Ничего сверх этого писать не надо. Ну кроме одного случая, который я описал, когда воркер завис.
Падажжи, ты собираешься держать транзакцию все время пока работает воркер?
>строкам присваиваешь
>блокировка не нужна
Бля, кретин ебаный. Во первых, во время "присваивания" строки будут заблокированы. А во вторых, на таблицу с миллионом записей тебе придется сделать миллион апдейтов.
Лол, так ты вообще не из айти. Дай угадаю: ты сраный препод из сраного замкадского каледжа. Ох уж эти провинциалы!
Нет, пока он строки не получит для работы.
Перечитал, понял, что ебануто написало про "воркер отработал". Имел в виду "воркер отработал с БД", а не вообще всю таску.
Окей, как ты лочишь таски, чтобы другой воркер их не начал обрабатывать?
1.
SELECT id
FROM queue
WHERE status = 0
LIMIT 10
FOR UPDATE SKIP LOCKED;
2.
UPDATE queue
SET status = 1
WHERE id IN (<список>)
RETURNING id;
Плюс дополнительно можно pid воркера записать сразу, и периодически проверять, что он не помер или не завис.
Постгрес. В оракле не смотрел, можно ли так, мы всё равно с него укатываемся.
Конечно в НИИ лол, будешь сидеть там лет 50 на жопе ровно в расслабленном темпе делать, что там тебе надо без мозгоебства.
Параллельно можно где-то подрабатывать или частные заказики делать.
Я работаю сейчас в прямо противоположной сфере и меня так это уже заебало, что нет сил никаких. Соковыжималка, никому не советую.
Вот допустим пользователя надо удалить
1. Удаляется все записи каскадно.
2. Помечается удален, но запись остается
3. Удаляется все нахуй каскадно, но все записи переносятся в копию БД удаленных клиентов, это типа архив со всеми кишками, кто что заказал и прочее. И в таком случае как поддерживать структуру таблиц там и там - мне кажется бред. Проще софт делит сделать как в пункте 2.
Тут пунукт 2 обычно выбирается? А если юзер повторно с номера решил зарегатся то что?
Или как такое делается? Это бизнес процессы называются или как. Хотя бизнес процессы это другое, а тут как бы внутренняя хоботня - вот как такое называется?
Где про эти механизмы можно прочитать и кто это делает? Архитектор? А с кем он согласует подобное поведение приложения?
>Тут пунукт 2 обычно выбирается?
Да, история не удаляется, пользователь отмечается каким-то флагом внутренним. Потом через какое-то время вместо с остальной историей или удаляется, или идёт в бэкап.
>А если юзер повторно с номера решил зарегатся то что?
Решается теми-самыми упомянутыми тобой бизнес-требованиями.
>А с кем он согласует подобное поведение приложения?
С каким-нибудь из C-левелов, который за бизнес отвечает.
Стоит ли покупать Яндекс.практикум и ботать на работе?
На работке как правило есть 3-4ч для ебланства за компом, вот хочу купить курс и пройти его за +- год и перекатиться на что то более перспективное.
Вопрос - хватит ли пары часов в день и не перегорю ли я?
Алсо, если есть какие то ресурсы типа читаешь тему и тут же делаешь какой то урок (по Питону, Джаве, неважно, по всему) - то кидайте, буду благодарен.
Видосики смотреть в опенспейсе сами понимаете палевно.
Нет, двух часов в день не хватит, люди этот курс как работу проходят целыми днями в течение месяца.
там курс 7 и 10мес расширенный, пишут что 10ч в неделю в среднем
Брешут. Все, с кем я говорил и кто проходил этот курс, говорят, что если ты идёшь в него с нуля, то готовься рвать жопу по 10 часов в день, иначе завалишь дедлайны. Плюс к этому у них постоянно что-то отваливается, и задачи из-за этого не принимаются. Менторы могут стабильно игнорить.
Да, достаточно. Некоторые кликхаус ещё любят спрашивать, но упор в него делать не надо, на работе разберёшься, если попадётся.
>учу с переменным успехом SQL и параллельно начинаю осваивать Hadoop, Spark, Kafka и Airflow. Этого достаточно?
Типичный пример resume driven development. Чувак просто вычитал в интернете какие-то баззворды, зачем они нужны - сам толком не знает. Он даже не понял, что сказал. Хадуп и спарк. Там где стоит хадуп - там не будет спарка. И наоборот. Сейчас все эти громоздкие кластеры уходят в небытие. Нет смысла в 2025-м году ебаться с хадуп кластерами. Проще дешево и сердито накатить duckdb. Хотя опять же, зависит от количества данных. Если у него 100 терабайт данных, то конечно, спарк без вариантов. Тут какое-то квадратно-гнездовое мышление, на любой случай лепить спарк и хадуп.
Опять же... как ответить на такой вопрос, если допустим более новый подход (но меньше у всех на слуху) - chDB/duckDB/polars или более классический подход, который типа "правильный" и "требуют все работодатели". Spark/kafka/dbt/superset и т.д.
Выбор между более разрекламированными "общепринятой технологиями" так сказать и "cutting edge".
>Там где стоит хадуп - там не будет спарка. И наоборот
Ну хуйню же несёшь...
> Hadoop, Spark, Kafka и Airflow
Мне лень искать, но если кто-нибудь доставит ссылок и книг по теме, могу добавить в шапку после переката.
мимо опхуй
Какой же клеппман пидорас и так всю книгу:
1. Это говно
2. Это говно
3. Это говно
А КАК НАДО ТО БЛЯДЬ ПИДОР. И ТАК ПРО КАЖДУЮ ТЕХНОЛОГИЮ В КНИГИ - НЕ ГОВОРИТ КАК НАДО
В "реальных банках" апдейтом остатков на счетах не ограничатся и, как минимум, учитывают в той же транзакции ещё и статус документа-основания, если он уже проведён, то и делать ничего не надо.
Зумеры совсем ебанулись. Пикрелейтед что такое? Просто пиздец, человек реально заморочился и по пятьдесят сносок на главу сделал. Почти кажое свое слово и утверждение обосновал, откуда это, кто это придумал, ссылки дал. Не учел только что его книгу будут читать не специалисты, как справочную литературу, а какие-то долбобеы вместо фентези в метро.
Ну вот дальше пишет, законспектировал, ок. Но заебали уже эти качели
>>3407121
Пошел нахуй блоховоз
В реальных банках пользуются такой разработкой древних как "двойная запись". Никто не "меняет" баланс. Никто ничего не вычитает и не прибавляет. Добавляется строчка в таблицу, с идемпотентным ключем, в котрой id счета дебета, id счета кредита и сумма. А когда пользователь смотрит свой "баланс" ему показывают "сальдо" - разницу между суммой по кредиту его счета и дебету.
Все эти данные хранятся в одной таблице, получаются быстро и легко, никаких конфликтов при записи не возникает потому что операции атомарные. Никаких отрицательных чисел в системе нет. А чтобы не выбирать все записи в таблице по счету есть операция "закрытие периода", когда создается запись с "сальдо" на закрываемый период и актуальный "баланс" считается по записям после закрывающей.
Нет это ты иди нахуй. А лучше в школу, где тебя научат пользоваться сносками в книгах. Автор тебе буквально дал ссылку на научную работу из которой он взял свою фразу.
Нахуй иди, я мать твою ебал.
Ору с пидора - его нахуй посылают, но омежке требуется внимание, т.к. друзей нет и не с кем поговорить. Приятно когда отвечают в ответ, кек
Я написал те технологии, которые на слуху. Естественно я планирую глубже разобраться, что и для чего используется. Зачем у тебя пукан подгорает? А эти кластеры точно уходят? Не слышал, чтобы Сбер или ВТБ использовали что-то отличное от этого.
Он не разбирается, игнорируй его. Кроме хадупосраки в РФ используют яндексовский ytsaurus в Яндексе и ВК. Тинёк и ВБ пилят свои дата лейки, можешь в эту сторону посмотреть ещё.
Ну ты просто слышишь, а я реально использую и плачу из своего кармана. Тебе похуй, не ты же платишь, а работодатель. Поэтому у нас цели разные, я стараюсь экономить, выбираю эффективные решения. А ты выбираешь по принципу "требуется в объявлении/не требуется". Один хуй, у Сбера кошелёк бездонный, они хоть миллиард рублей оплатят.
Хадуп нахуй не нужен. Почему? Потому что это джава, мап редюс - это тот же апач спарк на минималках. Hdfs? Есть s3, minio. Apache hive? Тоже устарело. Вся экосистема хадупа - говно.
Естественно, можно взять аренадата за охулион рублей в месяц и использовать для простых пайплайнов. Опять таки, тебе похуй потому что обычный исполнитель.
> Никто не "меняет" баланс.
Очень даже меняют, никто не будет ждать закрытия операционного дня, чтобы каждый раз для каждого счёта вычислять доступные остатки по сотням тысяч проводок/резервов ради проверки, что счёт не уйдёт минус после очередной проводки.
При закрытии дня, да, один раз проверяют соответствие текущих остатков проводкам и записывают в главную книгу.
Ну так это никакой не "баланс", а кеш, который в редисе вообще спокойно лежит и периодически в базой синхронизируется. Речь идет о том как финансы в базе хранятся и учитываются. Проводками и хранятся. То что там сверху нагорожено для скорости и удобства - вообще отдельная тема. Так-то все эти записи еще и в памяти приложения загружены в виде объектов. И в кафке в виде событий. И хуй знает где еще. Но источник истины в этой системе - таблица с проводками.
Всё, что можно сделать через GROUP BY, также можно сделать через оконные функции ( F() OVER () ) и DISTINCT.
>Хотелось бы куда-то расти, но я немного потерян.
Долбоёб, уж определись или тебе развитие или джуниор. Это две разные вещи. Вы сначала приходите говорите "дайте мне легкую работу" или "дайте мне стажировку", вам начинают советовать тестировщиков, junior должности и т.д. Вы устраиваетесь, и тут вдруг оказывается что там 0 развития, 0 опыта, по сути монотонная, скучная, лёгкая работа, которая никак тебя не продвигает как специалиста. Если ты хотел развития, не надо было устраиваться на должность junior-аналитика, надо было брать сложные таски (без приставки "junior").
Это примерно как работать 5 лет говночистом и ожидать, что эти 5 лет засчитают за опыт гендиректором, такая же логика. В смысле, ты получил ровно то что хотел - если ты хотел лёгкий ВКАТ то ты именно ВКАТ и получил. Про развитие никто не говорил.
Да, в общем-то я хотел легкий вкат. Ничего страшного, стаж получу в банке, а вечерами могу и посаморазвиваться. Вопрос был скорее в том, что поизучать, на что потратить свое маленькое свободное время, чтобы потом устроится получше. Уйти всегда можно.
Представь себе, что я допустим даю тебе ЛЁГКУЮ РАБОТУ. Без разницы какую. Скажем, она загружает твой мозг на 10%. И к чему это приведёт через 5 лет? Ты просто отупеешь. Если тебя ни о чём не просят, то они и не оценят твою инициативу. Ты начинаешь всякие tableau в свободное время устанавливать, это будет тоже самое, что кормить свинью моллекулярной кухней. Банку это нахуй не обосралось, они ещё за инициативу отругают лол. Лучше бы нашёл нормальную компанию, которой этот самый tableau реально позарез нужен, а не просто ебучие пет-проекты делать. Какая тебе разница на что время всирать, а так ты хотя бы за это деньги получишь. А так ты просто всрёшь время и нихуя никаких денег не получишь.
Смысл вот устраиваться на такую работу, где требуют меньше, чтобы вечерами пилить дополнительные пет-проекты. А нельзя было сразу подобрать такую работу, где это всё в требованиях содержалось? То есть чтобы там был и tableau, и python, и всё прочее.
иди раст разботчиком за 10 тыщ евро. нахуй тебе эти нищеброды и sql.
Так может эти tableau чем-то лучше, чем тот же эксель, правильно? А значит и я смогу потом начальника убедить, что нам это надо как минимум потестить, да сынициирую так сказать установку да постараюсь имплементировать в рабочий процесс.
Я так-то не спорю, я вижу в твоих словах логику. Ретроспективно я многое бы поменял, но надо играть с тем, что есть. Полгода назад мне очень легко достался этот офер и из-за своей лени я просто согласился на него.
Кто ж тебя возьмет. За такие деньги там уже 20 миллионов индусов откликнулись на вакансию.
Это всё имеет смысл делать, для тех кто в разбирается в теме и может оценить твой труд. Внедрение супер-пупер новшеств для несведущих людей чревато. Это всё равно что быдло накормить молекулярным обедом, принести лимонное облако и икру из дыни на ветчине прошутто. А он скажет - а нахуй ты мне это принёс, я хотел шашлыков поесть с балтикой девяткой.
Конечно сейчас ты сидишь на кукане, ты подписал договора, никуда сейчас не спрыгнешь. Надо было думать об этом ещё до момента подписания. Надо устраиваться туда, где сильная команда, много требуют. Можно учиться от других, если ты с первоклассными чуваками работаешь.
Tableau - как по мне, хуита из хуит. Они ушли из России, плюс, стоят космически дорого ~$1200/год на одного пользователя. По сути, это тот же самый R, только визуальный. С кнопочками-хуёпочками, вместо кода ты лазишь по менюшам и выбираешь готовые функции, вот и всё.
Мне понравилась твоя фраза про молекулярку и свинью, я даже в голос проиграл. Надо запомнить.
Но я не согласен по поводу новшеств. Если инициатива принесет пользу и эту пользу можно показать на пальцах, можно выторговать больше ответственности. Ответственность потом обменять на деньги. Только так я получал повышение в зп раньше.
Легко говорить - надо было что-то делать. В сильной команде может меня никто и не ждал. Опыт работы у меня все-таки в другой отрасли. Кстати, я не в РФ, я в Чехии, но может и вернусь, пока не знаю.
Мы сейчас просто гипотетические сценарии обсуждаем. Переубеждать нет смысла. Считаешь что нужно - ну окей. Практика покажет - нужно оно было или нет.
Ну может с одной стороны и неплохо. Может я просто нагнетаю. С одной стороны, копеечка капает, жить можно. Европку посмотришь.
Лично я бы вкачивал статистику, SQL и R, самые ценные скиллы для аналитика. Но это лично моё мнение.
Я думал меня тут сразу только нахуй пошлют, а ты мне даже релевантную информацию выдал. Благодарю.
Вклинюсь в ваш диалог. Я пиздец люблю R и много на нем всякого разного делал. Но сейчас объективно на рынке труда R никому не нужен. Для аналитики, статистики, всякого разного дата саенс всем нужен питон. Так что советовать кому-то тратить время на изучение R, которое можно было бы потратить на тот же питон или SQL - это просто нечестно.
>Я думал меня тут сразу только нахуй пошлют
ДУМАТЬ это одно, а проверять на практике другое. Я думаю что меня отошьёт вон та красивая девушка, но проверять я конечно не буду. Лучше сразу к жирухе подойду, так у меня больше шансов.
>>3409464
>Я пиздец люблю R и много на нем всякого разного делал
Молодец. Я тоже.
>объективно на рынке труда R никому не нужен
В точку.
>советовать кому-то тратить время на изучение R
Нет, подожди, ты сейчас путаешь кислое с пресным. Твоя мысль "не востребован - значит изучать не надо". Так можно сказать про что угодно. Matlab не востребован, изучать не надо. Julia не востребована, изучать не надо. Если на всё смотреть через призму найдёшь работу/не найдёшь, то нахуй нам все остальные языки. Давай все станет питонистами, нахуя нам раст, нахуя нам сишарп. Оставим только один питон и все на нём будем кодить. Чисто для себя можно изучить. Что значит "тратить время"? У языка есть полезное применение! Да, он может быть с недостатками или не такой популярный как питон. Но лишней строчка в резюме не будет. Язык позволяет красиво графики рисовать например, работать с временными рядами. Тем более, мы говорим про рынок евросоюза, а не российский. Если он и правда в Чехии, то там дохуя работы на R.
Так а какой серьезной компании нужен чел без реального стажа, пусть и на говноработе? Все серьезные вакансии требуют опыт работы. Просто все твои аргументы в разговоре с >>3409358 аноном касаются и меня. Я устраиваюсь аналитиком на пол ставки (ибо студентота) в парашу где не факт что sqlем вообще кто-то пользуется, и с одной стороны я долбоеб, что выбрал место с минимальным потенциалом развития, но с другой - где как не там я пойму, подходит ли мне эта сфера в принципе или нет. После года работы в любом случае планирую съебаться в более солидное место, где в серьезным ебалом заявлю об 1 годе опыта. Не знаю, анон, ты конечно прав, но легко сказать "надо было делать вот так-то и так-то, сразу залетай на мидла/сеньора", но в реальности все сложнее.
Не соглашусь. Я живу в ЕС, тут работы для R очень мало, а там, где R упоминается, обычно написано R/Python. Тем более, при чем тут матлаб и джулия? Никто не спорит, что лучше знать больше, чем меньше и лучше знать доп. язык, чем не знать, но он хочет вкатиться в аналитику как можно скорее и проще. А для этого логично бросить силы и время сначала на то, что более востребованно, а уже потом, работая, расширять кругозор и узучать новые языки.
Ты продаёшь не опыт, ты продаёшь заказчику аналитику своего бизнеса. Также как и строитель покупает не экскаватор, он покупает вырытую яму. Люди покупают не дрель, они покупают дырку в стене. Все эти: cертификаты, годы опыта, портфолио и т.д. Это лишь дополнительные свистелки и перделки для повышения цены, а не базовое условие для устройства на работу. Серьёзные компании? Блять, это какие? Типа ibm, майкрософта и так далее? А ничё что эти компании десятилетиями нанимают грязных вонючих индусов, работающих на них за копейки? Если ты считаешь себя хуже ёбанного индуса - ну окей.
Вообще, такого концепта как "быть достойным чтобы претендовать на работу" не существует в природе. Ну типа, ты либо делаешь работу и тебе платят деньги, либо обсираешься и тебя увольняют. Всё.
Также как и концепта "уволиться через год, потому что накопил достаточно опыта". Почему люди обычно увольняются? Потому что: 1) хотят больше денег 2) заебало на старом месте, не ценят 3) наскучило, хочется чего-то нового. А бля просто уволиться ради самого увольнения, это какая-то ебанутая причина если честно.
Ох, братик, я 8 лет в базах данных весьма плотненько. Был и Report Developer и DWH/ETL Developer так и сейчас в роли Data Engineer. Очень настопиздело это. Деньги тут можно зарабатывать, но в целом Data Engineer это человек-оркестр. От компании в компании ты будешь немного:
- DBA
- QA
- BI
- Python/Scala/Java Developer
- DevOps
- SQL
- системным аналитиком
- Support Engineer
Не жди что ты научишься хорошо программировать, ты будешь охуенно писать SQL-запросы, но не более. В разных компаниях по-разному, но ты будешь знать всё и ничего одновременно. Сам хочу уволиться и в Гошечку перекатиться, работаю в банке
>Гошечку перекатиться
охлол, я так же
только я сразу в гошечку не могу (нет опыта)
грустно на рынке сейчас для джунов, пиздец как грустно
В Джуна сложно, да. Я хочу в мидла. Есть опыт написания сервисов на петухоне. И в целом опыт в БД
вот я и думаю что делать, в запасе есть ~год на нахлебничество поднятие уровня знаний в бекенде
вот и думаю, стоит ли учиться пока я могу и всё же пытаться в golang, вдруг скоро всё закончится и к нам вернутся иностранные компании, в целом мировая экономика поднимется, и наконец то в айти будут вливать деньги как в ковидные времена и будет много мест для джунов
Мне казалось, что DE это что-то ближе к Hadoop, Kafka, ETL и вот это вот всё, а у тебя какое-то говно выходит будто
Мировая экономика нихуя не на подъёме, она нависает над обрывом кризиса и следующее десятилетие будет очень интересным.
Рекомендую тебе не ебланить и хвататься за всех синичек вокруг тебя, вместо того, чтобы смотреть на мифического журавля ласкового зарубежного хайра.
сейчас то понятно что всё плохо
господи найти бы работу в golang я был бы самым счастливым человеком в мире
Сейчас = все плохо будет как минимум десять лет и я не вижу в тебе понимания/осознания этого прогноза.
Заебало читать это нытьё про "человека-оркестра". Зуммеры постоянно жалуются ой блять "я хотел один бекенд а там ещё верстать..." или "я хотел бекенд, а меня ещё заставили разворачивать инфраструктуру, это нормально?". Они видимо ожидают микротаски или узкую специализацию. Где чуть шаг вправо, шаг влево - тут мои полномочия всё, как в том меме. Они ещё потом начинают скулить, типа лол, я же типа 5 в 1, должен получать как за пятерых человек мол! Хуле у меня такая маленькая зарплата, я хочу 500 тысяч в месяц. И ещё наймите 10 дополнительных специалистов - одного девопса, одного тестировщика, одного дба, и т.д. Ещё с таким обиженным еблищем обычно говорят, типа ой компания не может ещё людей нанять. Ненавижу этих людей сука. Просто по одной фразе "человек-оркестр" можно задектировать что скажет дальше.
Здорова, коллеги! Ну чё, погоняем двхшечку? Что у нас здесь сегодня, смотрим?
Старина Дейта, старина Уолт, посмотрим. Я такую кстати ни разу ни проектировал, ща посмотрим.
Как она обновляется я не знаю. Ща соберем эту глыбу. Хыыых еле-еле сджойнил! Хе-хе-хе!!
Ща попробуем. Берите вместе со мной ребятки выгрузку с витринки. Лааадно пойдёт!))
Одно дело когда человек-оркестр в компании ООО "Кабан" где 1.5 разработчика. Тут понятно что ты - незаменимый. Жнец, гонец и на дуде игрец.
Другое дело когда у вас есть целый департамент архитектуры, отдельно девопсы, отдельно DBA и дохуялион АНАЛитиков, но всё вышеперечисленные делаешь почему то ты. И поэтому перекос, одни отделы сидят дунасят, а других ебут потогонкой.
Изучай существующую структуру БД и разбирайся, почему она устроена именно так. Задавай вопросы коллегам (на которые тебе никто не ответит), думай где что можно было бы улучшить.
Тут как раз и возможен рост, особенно если что-то высоконагруженное с этой базой работает. Написать очередной круд на php и js много ума не надо, это и чатгпт сделает, а вот понимать, например, уровни блокировок, чтобы не напарываться на дедлоки на ровном месте, понимать зачем и когда нужны всякие индексы, квери планы, партишены, (де)нормализация — вот это самое сложное и ценное, это знания, которые ты дома/на говнокурсах не получишь никогда. И это то, что будет отличать тебя от таксистов со скуфбокса.
>Стоит ли дальше разбираться, это ведь, то, что нужно?
Это оно. Стоит ли или нет, решать тебе.
Это называется распределенные транзакции. Сделать можно, но некоторые считают, что в микросервисах их не стоит использовать.
Нельзя. Распределенные транзакции делаются через сагу и это большая головная боль для разработчиков. Самое простое решение - объединить все микросервисы в один, чтобы он все делал под одной транзакцией в одном подключении.
Где ты будешь прописывать логику откатов и ретраев в этом твоем двухфазном коммите?
> прописывать логику откатов
В самой СУБД.
> и ретраев
Нинужна.
Документация + sql-ex для понимания того, как на скуле решать задачи. Больше ничего не нужно.
У моего проекта архитектура говна. Микросервисы, которые нафиг не нужны. Я ничего не решаю, но хочется предложить что-то получше саги, которая для нашего случая оверкилл, потому что таких транзакция немного
Как сага может быть оверкилом? Одна транзакция, одна сага, одна таблица, один вождь файл.
Ты пытаешься добавить в проект idle in transaction. Так делать не надо.
Выглядит это сложно, чел на совещании рисовал схему, там нужно еще какие-то сущности вводить, а проект и так довольно запутанный. Хочется сделать именованную транзакцию, как будто это выглядит гораздо проще
>У меня есть несколько микросервисов
>которые обращаются к одной бд
Поздравляю, у тебя РАСПРЕДЕЛЁННЫЙ МОНОЛИТ.
Стоит ли ограничиться простым вызовом SQL COUNT(), перед созданием очередного заказа? Гипотетически, если много раз подряд вызвать запрос на создание заказа, то мы проскочим лимит, ведь нет никаких блокировок. Но с другой стороны, сильно за лимит уйти не получится в любом случае. Поэтому не знаю, стоит ли добавлять какие-нибудь блокировки или как обычно решают такие задачи?
Включи для этой транзакции уровень изоляции SERIALIZABLE и тогда точно никто не проскочит.
Буквально то что тебе нужно. https://stackoverflow.com/a/1743742
Вообще так делать не стоит, зато обеспечишь дба работой на годы вперед. Инвестируй в будущее.Твои дба братишки на новом месте работы отплатят тебе тем же.
Advisory locks чекни, чтобы блокировать записи конкретного пользователя а не все
Нейро ответы не писать!
Поисковые ответы не писать!
Писать только знающим людям!
Как разобраться с уровнями изоляции транзакций и понять когда и какую выбирать? Как не обосраться на собеседовании?
READ UNCOMMITED - никогда. Дебилы не знают про кафку.
READ COMMITED - всегда.
REPEATABLE READ - никогда. Каловое легаси с бизнес-логикой в хранимках, нет пути.
SERIALIZABLE - каво?
Ну и как понять, что каждый уровень делает? Не просто же их так придумали. На собесе каждый раз спрашивают перечислить все уровни и привести примеры
READ UNCOMMITED - изоляции нет, изменения доступны всем сразу, не дожидаясь комита. Транзакций по сути нет, если очень хочется пукнуть данными и забыть - есть кафка.
READ COMMITED - изменения становятся видны всем после комита своей транзакции. Это дефолтный режим.
REPEATABLE READ - перед началом транзакции делается как бы слепок бд и ты работаешь с ним. Если в режиме READ COMMITED изменения видны в твоей транзакции сразу после комита своей транзакции, то в режиме REPEATABLE READ ты работаешь со старой версией базы, какой она была на момент начала твоей транзакции. Эта хуйня актуальна, если ты в бд пишешь дохуя бизнес логики и в циклах что-то там считаешь. Сейчас так никто не пишет.
SERIALIZABLE - транзакции выстраиваются в очередь и следующая не запустится, пока не завершится текущая. Пизда производительности, никто это не использует.
>>3414550
>>3414478
Угу, а потом тебя спрашивают - мы тут работаем с Postgres, там MVCC, расскажити.
Вот книжка, в ней где-то в начале разбирается изоляция: https://postgrespro.ru/education/books/internals
Лол, причем здесь вообще уровень изоляции?
>>3414701
> SERIALIZABLE - транзакции выстраиваются в очередь и следующая не запустится, пока не завершится текущая. Пизда производительности, никто это не использует.
Чиво блять? Один пользователь может открыть несколько параллельных сессий и ебашить запросы. И просто результаты этих запросов не будут видны пока они не закомичены. Если два одновременно запроса заапдейтят одну и ту же строчку, то просто будет блокировка. Никакие запросы в очередь не выстраиваются.
Такие и задают. От джуна ничего особого не ждут, кроме 3 лет опыта.
Нихуя себе, прям представляю суперкомпьютер с выделенной электростанцией, на котором одиноко крутится постгрес.
Ходить конечно, это называется подышать свежим воздухом. У нас пара коллег курит, иногда выхожу с ними пробздеться, на солнышке постоять.
Разве я не буду дышать дымом большую часть времени? О чём с ними говорить, если мы не знакомы вообще
> Разве я не буду дышать дымом большую часть времени?
Нет, отойди подветренную сторону, там не пахнет.
>О чём с ними говорить, если мы не знакомы вообще
Ошибка сыча, о чем хочешь говори. Спроси кто сколько тут работает, чем занимаются в компании. Да хоть про сикуэль говори, главное не сиди в стороне.
Понял, спасибо. Но мне кажется на практике мозг просто сделает выбор в пользу "стоять и смотреть в пол"
Я этим фактом очень опечален, учитывая, что мне осенью будет уже 32. Всю сознательную жизнь после института мечтал о том, чтобы быть ценным спецом и получать за это справедливые деньги, но смачно поел говна. До того, как кривая завела в текущее положение, пытался хаотично вкатываться в аналитику. Помню сюда заходил и спрашивал, достаточно ли 57 прорешанных задач на sql-ex для собесов на джуна, ну и на кой-то хуй прошёл машин лёнинг курс от Эндрю Энга ещё в 2018, когда ЛЛМки были в зачатке.
Собственно подумал о том, чтобы попробовать продолжить путь аналитика, так как сложилось впечатление - по крайней мере по вакансиям, - что чем больше знаешь и чем больше работал, тем больше получаешь. Проще говоря трек развития понятный. К аналитике душа лежит побольше, прогерство не хочу. Кажется логичным будет пойти в продуктовую аналитику как смежное моей текущей работе. В ином случае пытаться корячится и начинать какой-то мелкобизнес, но меня эта мысль вгоняет в тоску. Поделитесь мнением, есть ли смысл вкатываться особенно учитывая риски связанные с ИИ, если они вообще касаются сферы аналитики или есть другие более эффективные пути, чтобы не остаться к 40 годам с голой жопой? Пардон, что насрал биопроблемами тут, обратиться особо не к кому.
От продуктового анала тоже часто требуется кодить, не только в БД ходить. Плюс А/Б тесты всякие и прочая статистика.
Другой вариант - системный анал, у них сейчас легко 300к+ получать, но не знаю как долго это продлится. Я считаю, что со временем пойдёт на спад, так как проекты, для которых они нужны, будут завершены, и их будут нанимать меньше и меньше.
По специфике я вроде плюс-минус в курсе, по крайней мере издалека продуктовый аналитик нравится больше, не знаю что нам на работе по факту. Тут скорее извечный вопрос - не поздно ли в 31 заниматься перекатами, и что происходит на самих местах? Есть ли такое же перенасыщение, как с разработчиками, или из-за теор вера и статистики порог всё-таки выше? Может работодатель скорее отдаст предпочтение студенту с МФТИ, ну и вот это вот всё. Хочется прикинуть риски.
Перекатываться не поздно, но ситуация такая же, как в остальном IT. Конкретно в аналитику перекатываются куча нормисов, которым тоже около 30-40, и мыслят они примерно так же "программирование это сложно и для задротов, а вот аналитика это легко, просто в эксельке графики делоть". Поэтому на вакансии сотни и тысячи откликов. И сами нанимающие редко понимают отличие между дата-аналитиком, продуктовым аналитиком, BI-аналитиком, системным аналитиком и бизнес аналитиком. Поэтому может так случиться, что название вакансии вообще не совпадает с задачами.
>не поздно ли в 31 заниматься перекатами
>>3424091
>есть другие более эффективные пути
>>3424091
>учитывая риски связанные с ИИ
Какой-то тупой вопрос. А между чем и чем мы выбираем? Между лежанием на диване и работой? Если ты жопу не поднял, никто за тебя шевелиться не будет. Понимаешь, жизнь как работает. Никому нахуй не обосралось твоё развитие кроме тебя самого. Хорошо было бы допустим, чтобы ты занимался спортом, читал книги, изучал новую сферу деятельности. Но! Если ты не будешь это делать, никто за это не накажет, палкой по хребту не переебёт. Это будет иметь отложенный эффект, например. Если ты не занимаешься спортом, у тебя появится животик. Причинно-следственная связь.
Так же и в айти. Не перекатывайся. Вон, смотри, там есть Васян, он любит айти, он пойдёт и твою зарплату получит за тебя. А ты хуй соси и думай о рисках дальше.
А почему ты не можешь задротить также как задротит приведенный в твоём примере студент МФТИ? Он какой-то волшебный что ли? Ты вроде также можешь зайти в интернет, найти материалы для обучения и дрочиться также как студент МФТИ.
Риски есть везде и всегда. Допустим, можно идти по дороге и тебя собьёт камаз. Это риск? Да. А здесь, это называется "упущенная возможность". Ты нихуя не теряешь если тебя не наймут. У тебя как 100 рублей в кармане было, так и осталось. Ты ничего не потерял и ничего не приобрел. Рискует здесь только работодатель, он рискует ВСЕМ. Он рискует потерять деньги, время, нервы, получить хуёвую криво сделанную работу, нарваться на штраф от государства, обанкротиться и так далее. Ты рискуешь только временем. И всё.
>почему ты не можешь задротить также как задротит приведенный в твоём примере студент МФТИ
Мозг разный.
Полностью согласен, ты неиронично прав, но не хочу особо свои биопроблемы разводить. Если коротко, причина моей тряски - страх, что если наебусь с выбором развития третий раз, то к 40 годам шанса уже не будет.
>>3424339
Я-то могу, вопрос в том, кого в реальности предпочитают работадатели: скуфидонов-вкатунов иди МФТИ студентов. У меня и образование так-то сравнительно хорошее техническое, просто ему 8 лет уже.
>>3424343
В моём случае имеется ввиду риск оказаться никому не нужным чмом без денег к критическому возрасту.
Ну ты понимаешь, бог дал тебе SQL, который просто работает, причём это длится уже полвека, скучно же, хочется чего-то нового. Вот и изобретают всякие графовые, документные, колоночные, key-value и другие СУБД для разнообразия, чтобы можно было поиграться год-другой и вернуться обратно к SQL.
>причина моей тряски - страх
Ну блин, к этому вопросу к психологу. Проблемы башки, навязчивые идеи, страхи, загоны и так далее - это он лечит.
>то к 40 годам шанса уже не будет
Чел ты ебанулся нахуй. За эти 8 лет можно горы свернуть, миллионы нажить, наебаться, некоторые по сотне книг в год читают. Естественно, если просто плыть по течению, то ты через 8 лет окажешься в примерно той же точке, что и сейчас. Для этого нужна воля и цель. Если жить без цели, то не будет никакого прогресса.
А зачем оно вообще нужно? Вот я не представляю как БД может быть надежна, например, key=value. В моем понимании это может быть полезно только в in-memory базах данных по типу редиса, где надо некоторые промежуточные данные хранить
Для промежуточных данных и нужны, чтобы в конце их сохранить в настоящую реляционную БД.
>Естественно, если просто плыть по течению, то ты через 8 лет окажешься в примерно той же точке, что и сейчас.
В том и дело, что я крутился как сумасшедший, почти все 4 года работал на двух работах, либо перерабатывал/вкалывал для команды, но в итоге это не особо даёт веса в поиске работы. Причём никому не даёт, почти все знакомые жалуются на рынок. Зарплата конечно выше средней по стране 130к, но это в среднем потолок в отрасли. Поэтому у меня ПТСР. Ну ладно, я понял позицию анонов и в целом согласен. С другой стороны не вижу, чтобы кто-то мгновенно называл подводные камни - это хорошо. Спасибо, всем добра.
>Зарплата конечно выше средней по стране 130к, но это в среднем потолок в отрасли.
Забыл добавить, что найти другую такую работу будет очень сложно, это самое хуёвое. То, что зп остановилась, даже не так обидно, как риск остаться с голой жопой, если кабан решит закончить свои дела. Ладно короче заканчиваю срать не по теме, ещё раз спасибо за дельные ответы.
Кабан, плиз, прекращай маняспектакль для вкатунов
Графы позволяют легко отображать сложные связи между объектами. В графовых БД некоторые виды поиска осуществляются намного проще и БЫСТРЕЕ, чем в реляционках.
Что же это за связи такие, которые нельзя сделать через джоин?
В графовых базах связь не вычисляется, а хранится. Там это не джойн, а селект. Объяснять насколько это быстрее надо? Особенно в ситуации с рекурсией, когда надо найти точки, связанные с точками, связанные с точками... Поиск друзей друзей, поиск возможных маршрутов, поиск предков/наследников.
То есть в реальных задачах это надо примерно никогда, иначе вместо постгреса везде был бы графгрес или что там есть.
Чел. Я привел тебе пример вполне реальных задач. Если твои данные формируют граф, то можно с выгодой использовать графовую базу.
Если ты попробуешь, например, заджойнить цепочкой с десяток среднего размера таблиц, то нагенеришь в памяти мусора на кучу гигабайт. А если представить те же данные в виде графа, то такой запрос оптимизируется в сотни или даже в тысячи раз.
Проблема в том что, тебе этот граф нужно собирать своими руками и в графовую базу запихивать. И такая оптимизация под конкретный запрос становится мягко говоря не такой уж и выгодной.
>>3430830
>>3430871
Ты, дружок, забыл добавить, что в большинстве графовых бд под капотом весьма реляционная таблица триплетов с накинутыми индексами, а язык чрезмерно декларативен. Отсюда отвратительный перформанс на запись при посредственном чтении, а попытки оптимизации запросов превращаются в цирковое выступление. Причем озвученные для реляционных бд болячки никуда не деваются.
>Если ты попробуешь, например, заджойнить цепочкой с десяток среднего размера таблиц, то нагенеришь в памяти мусора на кучу гигабайт.
У нас бд майкрософт, в главном гриде штук 50 джоинов, беспощадный документооборот. У кастомера стоит весьма грустный сервер, никаких йоба кластеров. Все работает, страница отдается меньше чем за секунду на 200к записей в результатах и дохулионе страниц в пагинаторе. Просто надо нанимать разработчиков писать sql, а не мартышек с orm головного мозга.
Конечно, любые связи можно сделать через джойны. Вот только запросы в итоге могут быть километровыми.
Вон в Sql Server'е есть встроенная фича SQL Graph - https://learn.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview - Узлы и грани в двух таблицах хранятся. И добавлен синтаксис, делающий запросы более лаконичными.
А под капотом реляционных БД списки и деревья.
>а язык чрезмерно декларативен
Ну дык в этом и суть! Не колупаемся с императивными циклами, а лаконично получаем данные.
Не, я не агитирую за графки. Просто пытаюсь сам для себя прояснить некоторые моменты в беседе с умными людьми (да, мы тут такие!)
С какими такими циклами ты колупаешься в SQL?
Происнить моменты легко: просто берешь и смотришь на требования к вакансиям. Это реальные люди используют реальные субд для реальных задач, а не теоретики сидят фантазируют. Постгрес есть, редис есть, кафка есть, графов нет.
>Просто надо нанимать разработчиков писать sql
Охуенно деграднули. Лет десять назад дба как раз разработчиков хуй бы подпустил тяжелый запрос писать.
ДБА написанием всех запросов не занимается. Для этого есть специальные скуль девелоперы.
>Для этого есть специальные скуль девелоперы.
Хуйню не неси.
Вообще да. В канувшым в лету недавно Киви Банке были роли DBD. Database Developer. Челы которые в Оракле срали функциями, процедурами, запросами. Например на некоторых проектах кредитные конвейеры были написаны на Оракле. Чисто в базе. В пакетах и функциях. Работало охуенно быстро.
Из минусов сложнее делать полноценный деплой и хранимые процедуры в гите хуита.
А DBA делают чтобы это все не падало.
>DBD. Database Developer. Челы которые в Оракле срали функциями, процедурами, запросами
Вот я про них и говорю. ДБА такими вещами не занимается, максимум может посмотреть что-то совсем криво работающее по метрикам и помочь исправить. Но сам писать с нуля запросы для других он не будет, потому что он один, а условных бэкенд-макак на него будет пара десятков, и если для каждого писать все запросы, то у него не останется времени на свои основные обязанности.
>А под капотом реляционных БД списки и деревья
А что сказать-то хотел? Я - (видимо нужен сурдоперевод), что перформанс у графовой бд будет дай бог не хуже, чем CTE у реляционок. Кроме, допускаю, полутора специфических запросов на не менее специфических данных - которых, кстати говоря, я так и не встретил.
>Не колупаемся с императивными циклами, а лаконично получаем данные
А не хотел ли ты запросик, в котором от позиции стейтмента (напомню, из-за избыточной декларативности у тебя все стейтменты внутри группы коммутативны) у тебя тайминг разнится на четыре ебаных порядка? А я с таким ебался год.
А можно вместо пиздежа типа "траст ми бро" увидеть бенчмарк?
>Когда их применяют? Какие юзкейсы?
1. Заказываешь ты переговорку для митапа. Выбираешь в вебморде адрес, дату и время проведения, затем в списке свободных переговорок, подходящих под фильтр тыркаешь на названии/номере комнаты. На ЭТОМ САМОМ моменте хорошо бы залочить эту переговорку для заказа, чтобы она исчезла из списка свободных для заказа на это время. Т.к. потом у тебя открывается большая форма заказа переговорки. Пока заполняешь название встречи/повестку встречи/то/сё/хуё моё/вставляешь почтовые ящики десятка коллег, которых нужно пригласить, проходит минут 20
2. То же самое, но для товара в и-нет магазине. Чтобы его успел купить именно ты, кто первым начал оформлять
Пример с магазином сильно кукаретический и притянутый за уши. Обычно просто делается повторное чтение когда ты форму сабмитишь. Либо в критических местах создается запись с бронью. Локи и долгие транзакции не совместимы с вменяемым перфомансом.
Неявные блокировки происходят, когда ты изменяешь данные: insert update delete вот это все.
Явные FOR UPDATE на практике никто не использует кроме совсем упоротых, кто не слышал про кафку. Блокировка делается на уровне бизнес логики: надо забронировать товар - делаешь колонку lock_date и туда пишешь крайнюю дату блокировки, в where проверяешь.
Надо изучать не в ширь, а в глубь. Изучи хорошо что то одно, а остальное интуитивно понятно будет.
В смысле нехуй? А как же построение масштабируемых, консистентных, надежных, отказоустойчивых систем?
>масштабируемых
Шардирование к бд не относится.
>консистентных
Импосибл.
>надежных
С репликацией ебется дба.
>отказоустойчивых
С кубером ебется девопс.
Ну нихуя себе. А разрабу что делать-то тогда? Таски из джиры пилить, и нет другого пути?
Всякое говно, но с нуля и с очень маленькой командой. Нет роскоши делать готовые, оформленные тикеты из таск-трекера. Все приходится продумывать, делать и распределять самому. Хуевые процессы - возможно, но лучше так и иметь полную техническую свободу и ответственность, чем закрывать таски.
В Ростов-на-Дону ехать что ль? На удалёнку эти челы ток middle берут, а джунов в офис. Хули я родился в этих пердях, тут ток 1С.
С нуля сможешь БД поднять без гайдов? Ролевую модель сможешь навесить? Сделать горячие бекапы сможешь?
Это база, братик. Я знаю это как таблицу умножения. Для джуна-то наверняка хватит, но для мидла ведь надо ещё докинуть девопс-практики. Я в них пока не бум-бум.
Огромная пиздец
Что? Ну я никуда не спешу, всегда беру книги на будущее по скидонам. Чувствую себя волком с уоллстрит, лол.
Ну и когда Кабанов прочитал с монитора 640 страниц - охуел, один глаз хуево видеть стал. Потом так же ебанул 500 страниц другой, только бумажной - земля и небо по комфорту
Вау, вот это ты молодец! Аш целую книгу купил! Вот это ты зверь, монстр, ах тыж книголюб ты наш. Айкю наверно зашкаливает. Целых 640 страниц, вот это да! Я поражён до глубины души. Никто такие большие книги не читает как ты. Достоин получения медали как минимум.
Я просто злорадствую. Прям такой понт ОЙ ПАСАТРИТЕ Я КНИЖКУ КУПИЛ ЮХУУУ! Если я бы писал о каждой купленной книжке на двач, модератор запарился бы тереть мои посты.
Тут вообще понтов нет, просто ты пидор залетный в айти, а в моем понимании каждый программер имеет свой шкаф с мукулатурой, поэтому и кинул скидон на книгу. Но а в твоей картине мире поридж читать киниги это СЛОЖНА ХНЫ О УЖАС КНИГА ОН ХЗВАТАЕТСЯ КНИГОЙ
Нахуй иди залетная мразь, это не твоя профессия
Ох ты ж и клоун эдакий... Пыникс, на будующее — поменьше гонору, а то падать будет ой как бооольно, ты уж поверь дяде.
Я когда ебу твою мать, ей так же про тебя говорю - пиздюка своего в кладовке держи когда я прихожу, а то бегает во круг, мешается
Это кринж для скуфов, челик, его уже не перспективно ракать в 25 году, не слушай этого >>3440354 пердикса.
Большая тройка: DB2, Oracle, Sql Server - никуда не делась.По-прежнему тянут гигантскую нагрузку. Но дорого, да...
На коне сейчас Постгря. Бо бесплатная. Но конченая, шо пиздец... Глаза б мои её не видели. :(
Пых + Мускуль как и прежде являются основой этих ваших ынторнетов. Так что можешь смело учить, на хлеб с чёрной икрой всегда заработаешь.
Опять же, самая массовая СУБД - Sqlite - как была, так и остаётся самой массовой.
>Пых + Мускуль
Легаси кал.
Назови хоть одну причину, нахуй нужно это недоразумение, которое ни одного SQL стандарта не поддерживает в 2к25 году?
>ни одного SQL стандарта не поддерживает
И чо?
Redis, Mongo и десятки других нереляционных СУБД тоже Sql-стандарт не поддерживают, но на них можно сваять любой сайт/сервис.
Сайт/сервис можно сваять хоть сохраняя данные в текстовый файл. Это не отменяет того факта, что мускуль - самый кривой ублюдок в SQL семействе.
От вопроса ты очень тупо вильнул сракой. То что на кривой залупе можно че-то там сделать - не повод это делать. Реальные причины использовать это убожество будут?
А зачем по мускулю книгу покупать? Ты что, работаешь на зарубежного работодателя? в РФ мускуля мало
Бля, зачем вы кидаетесь на чела, который просто книгу по СУБД купил? Он изучит нормально одну СУБД, потом легче будет другие изучать.
Во-первых, купил. Уже долбоеб.
Во-вторых, на русском, а не в оригинале. Дважды долбоеб.
В-третьих, книгу по мускулю. Трижды долбоеб.
Над такими долбоебами грех не поугарать. Нам - веселье, им и другим - наука.
Такие как ты потом онкологией заболевают, но сначала горло отбывает - злость, токсичность это выделение гормонов концентрат котрых действует как яд. Такая смерть обычно называется кармой, а под капотом такие механизмы работают.
Он потомок наверное тех кто книги сжигал на улицах и детей на штык ножи насаживал, у таких людей обычно все семейное древо такое из упырей и скота, людоедов, с зеками и алкоголиками
Сап анончики. Волнует такой вопрос, а насколько вам не хватает тулзы для проведения перформанс тестов БД? Или просто ограничиваетесь explain/analyze?
>тулзы для проведения перформанс тестов БД
Представь себе небольшую внутреннюю ерп систему на сотню таблиц и сотню пользователей онлайн. Солнце погаснет раньше, чем ты переберешь все возможные комбинации запросов. Я поначалу вообще индексы не пишу, потом уже на живых данных добавляю где надо.
Ну так пиздуй на пикабу и там рассказывай: как покакал, какой у тебя виндовс, покупки свои. А тут твои высеры нахуй не нужны. Пиши полезные вещи, и никто оскорблять не будет.
>Солнце погаснет раньше, чем ты переберешь все возможные комбинации запросов.
Не, речь не об этом идет.
Я исходил из той ситуации когда к примеру есть конкретный функционал/http запрос который тормозит, к человечку пришли с этой проблемой и вот он собрал статистику по запросам из БД и примерно видно в чем может быть проблема, но чтобы подтвердить свою гипотезу ему нужно воспроизвести её чтобы ну вот точно уверенно говорить в чем проблема. Такие ситуации часто бывают или я её из пальцев высосал?
Конечно он сам не будет сидеть и писать тестики, в этом случае можно посадить куа макаку или разраба который проведет перформанс тестирование исходя из статистики по запросам которую ему выгрузили
> Питарахен наделил себя мандатом указывать кому-что что кому делать
Ты можешь только терпеть, блохастый. Я твою родную мамулечку еще хуй об ее губы вытирал
У тебя какой-то слишком формальный подход. Есть проблема от кастомера - грид тормозит. Сделали таску, починили, куа подтвердил - проблема решена. Никто никакими верификациями не занимается.
В современных СУБД вроде есть внутренние метрики, которые можно к той же графане подключить и смотреть.
В логах, если по какой-то причине их надо держать именно в БД.
А если в json содержит к-л заготовки данных для функций,то просто хранить как файл в системе?
Хранить то можно. А вот менеджить, редактировать там, поля добавлять убирать - и сам заебешься, и базу заебешь.
А че как в монге переименовать какое-то конкретное поле для всех документов? Перепутали немного и вместо названия поля "colour" написали "ПИДАРАС". Как поменять?
Никак, надо на каждом документе держать поле "версия схемы", а в приложении для каждой версии схемы дёргать нужную версию репозитория.
У тебя на пикчах девопсы. Дата инженеры тут ну и я
Офис нахуй. Щас бы в 2k26 в офисе от жары вариться вместо того чтоб на свежем воздухе в лесу из палатки работать.
Работа интересная хотя бы?
Ты где офис то увидел, билять? Какой нахуй палатки? Самое удобное рабочее место твоя недвига где куплены OLED мониторы, топовое кресло и стол. Ты ещё пиздани про мантру - работа с пляжу!
Вкатиться реально? Конкуренция ниже, чем в куа/фронтенд?
Говнокод - это писать бизнес-логику на SQL. Так что забей, хуже уже не будет.
Если это хранимки, то очень плохо. Если обычный скуль, то зависит от того, где и как он хранится. Если прямо внутри языка в сыром виде хранишь, то плохо, если отдельно, то приемлемо.
>Если это хранимки, то очень плохо.
Да, в хранимых процедурах. Ну я так и думал, что попал не пойми куда. Анлак
> Если это хранимки, то очень плохо. Если обычный скуль, то зависит от того, где и как он хранится. Если прямо внутри языка в сыром виде хранишь, то плохо, если отдельно, то приемлемо.
А как SQL можно хранить отдельно? Реализовывать запросы к БД силами самого языка?
>А как SQL можно хранить отдельно?
Например, есть инструменты dbt или sqlmesh, они как раз для того, чтобы выполнять трансформации через чистый SQL. В итоге у тебя файлы с запросами хранятся так же, как обычные файлы с кодом, и их можно версионировать и всякие анализаторы по ним гонять. Плюс ты получаешь граф того, какие таблицы откуда берутся.
>Реализовывать запросы к БД силами самого языка?
Можно и так, если в самих запросах каких-то сложных подстановок нет (хотя и это сейчас вряд ли проблемой будет).
>Говнокод - это писать бизнес-логику на SQL.
Такая логика работает только если у тебя простейший детсадовский круд. Если у тебя запрос на пару страниц, то логика там сто проц будет. "Если сегодня не пятница" или "Если в таблице с настройками установлен флаг" или "Если у пользователя меньше десяти залуп за воротником".
>Например, есть инструменты
Хранишь ddl процедур в гите и в бороду не дуешь. Дешево и сердито.
>Хранишь ddl процедур в гите и в бороду не дуешь
Хранить код вне СУБД в любом случае нужно. Только дальше проблема - как его раскатывать после изменений? Нужно прогнать тесты как минимум. Потом если что-то поломается, то надо смотреть, какие из процедур связаны с отломавшейся. А графа зависимостей нет, надо руками смотреть.
Эти вопросы решаемые, но проблема всё равно собственными руками создана.
Лол, а обычные запросы ты как тестируешь? Да никак в 99% случаев. Скомпилилась процедура уже заебись. А правильность возвращаемых данных пусть тестеры на стенде тестируют.
>а обычные запросы ты как тестируешь?
На тестовых данных выполняю. Для этого не надо её компилировать сначала в тестовой схеме, потом в остальных.
А тестовые данные где берешь? А правильность этих данных как проверяешь? А редактируешь их как? Раз процедура поменялась, то данные скорее всего тоже.
Как не крути, а это один хуй критерии приемки, которые должны писать тестеры и аналитики. Разработчик тут нахуй не нужен, его время дороже, и дел у него своих хватает.
Тестовые - подмножество продовых. Правильность данных обычно проверяю инкрементно - сначала руками проверяю очень маленький набор, из них вывожу критерии, проверяю чуть больший набор, если критерии вывел неправильно, то добавляю данные, на которых не сработало, в тестовый набор. Повторяю так ещё несколько раз, пока не станет правильно. Изменяю точно так же.
Но так как сырые данные идут от внешнего источника, на который я никак повлиять не могу, то изменения схем - редкое явление.
Я бы с радостью эту рутину отдал бы кому-то, но тестеров у нас нет (мелкая компания, не гос), во-вторых, они вряд ли бы глубоко вникали в данные и поняли бы, что вообще надо тестировать.
Я разговаривал с несколькими людьми из бигтеха российского, они мне рассказывали, что тесты к данными они тоже сами писали (дата аналитики и дата инженеры). Поэтому не думаю, что это какая-то редкость. Но допускаю, что чистые разрабы не пишут такое, они по тз сделали и дальше за стену перекинули.
>Тестовые - подмножество продовых.
Откуда они на проде возьмутся если пилится новая фича.
>Я бы с радостью эту рутину отдал бы кому-то, но тестеров у нас нет
>мелкая компания
Поэтому переплачивают за низкоквалифицированную рутину, профессиональным кадрам, которых и так дефицит. Типичное кроилово от долбоебов.
>Откуда они на проде возьмутся если пилится новая фича
Из сырых данных с источника. Я периодически проверяю обновления схем, которые он выкладывает, и если там есть изменения в чём-то, что я обрабатываю, то начинаю менять парсеры и трансформации. Или если я пропердел в стул обновления схемы, то данные с новой схемой уже есть.
Всё, что я делаю на своём проекте, крутится вокруг этих данных, поэтому тут сильно не разбежаться с возможными фичами.
ХЗ что у них с производительностью.
Реально видел один пример
Так и нахуй ты высрался если не знаешь?
Во первых, у тебя транзакция висит хуй знает сколько. Сколько ты будешь заказ оформлять? Минуту? Час?
Во вторых, у тебя с этой транзакцией висит коннект к базе. А это значит либо кому-то другому этот коннект не достанется, либо надо увеличивать количество коннектов в пуле.
В третьих, у тебя пишется в базу инфа о локе. Запрос на SELECT, а перфоманс на самом деле на INSERT или даже кучу инсертов.
Ну и в четвертых, у тебя другие транзакции по этой записи блокируются. На примере с магазином: чувак, который пришел вторым будет сидеть и ждать первого хуй знает сколько, потому что не сможет сделать свой SELECT FOR UPDATE.
КУЧА проблем. Нахуй никому не нужных кста. В сто раз проще перепроверить еще раз есть ли в наличии выбранный товар.
для обновлений данных в форме делают через оптимистическую блокировку. При чтении данных отдаем в форму версию данных, форма при запросе обновления передает версию данных и мы сравниваем с текущей. Если отличается - выдаем ошибку "кто-то обновил данные"
Опять же очень утрированный вариант. Который подходит для какого-нибудь очень простого круда в вакууме.
Форма создает ЗАКАЗ. Отправляет на бек КОРЗИНУ. А изменения происходят в ОСТАТКАХ. Никто не будет передавать версии остатков каждого товара. Версия оставшихся прокладок 33, а версия оставшихся груш 15. Бред.
Таблица остатков вообще скорее всего какой-нибудь синтетический junction table в котором только идентификаторы или собранная огромным запросом вьюха или вообще отдельный сервис.
Вот приходят ко мне и говорят у нас вчера ниработало, долго выполнялся запрос и т.д.
Посмотрю я в какой заббикс э, увижу там инфу по загрузке памяти и цпу - а толку? Загляну в пг_статс_статемент по торгам, сильно понятнее не станет.
Как узнать что творилось в моменте?
Логировать perf и выставлять log_statemebt в all?
Я верю что можно лучше придумать.
Как в потешном постгресе не знаю, это же игрушечная субд, а у меня в промышленном MSSQL есть трейсы. Это лог со всей информацией, там и время выполнения, и тексты запросов, и нагрузка на систему. Прошу трейс от кастомера, дальше анализирую.
Средние. Обычно там поддержка хранимок с бизнес-логикой, адхок-запросы для аналитиков и тому подобное. Расти чистым разработчиком SQL/БД особо некуда. При желании можно перекатить в смежные области, но для этого не обязательно страдать.
А какие у него смежные области? ETL-кал и администрирование БД (считай техподдержка). Лучше уж в бэк или DevOps какой-нибудь
>ETL-кал
Это. Дата инженегр, ETL-разраб, DWH инженегр. Названий много, суть одна. Лучше это или нет, анону самому решать. Может у него стояк жёсткий от работы с БД и обработки данных.
Спасибо за совет. Приму к сведению
>>3454465
А ты сам работаешь там? Как я понял из гугления, это что-то среднее между администрированием и перегонкой данных из БД в Excel
Да, я ETL-макака по обязанностям. Забрать данные из источника, распарсить, положить в БД, преобразовать в нужный клиентам вид, перегнать в БД, откуда клиенты будут брать через веб-UI. И чтобы это всё было автоматически без простоев и потерь (на самом деле всем похуй, могу хоть руками каждый день запускать, но мне лень). В эксель обычно аналитики выгружают и сами вертят как им надо. Но если ты один айтишник в компании, то да, придётся ещё и по запросу в эксель выгружать.
Администрировать ничего не надо, если есть хотя бы сисадмин, который тебе развернёт окружением со всеми инструментами. Но я сам разворчачивал всё кроме сервера. В больших компаниях всё готовое дадут (наверное).
Спасибо за ответ. очень интересно узнать детали. Какие инструменты автоматизации/разработки используешь? Airflow/dbt какой-нибудь? Докером не пользовался? Я вот просто думаю параллельно работе учить технологии для ETl/DWH
Airflow для автозапуска, dbt только рассматриваю и сравниваю с sqlmesh в контексте работы с кликхаусом. Пока что все скуль скрипты запускаю из питона напрямую.
Из БД оракл (с него укатываемся), постгрес (на него перекатываемся) и кликхаус для расчётов. В докере только оракл держу.
Хадупосрак и им подобных у меня нет, объёмы данных маленькие, всё онпрем на одной машине считаю.
По инструментам есть две ссылки платиновые:
https://www.pracdata.io/p/open-source-data-engineering-landscape-2025
https://mad.firstmark.com/
Их можно просто посмотреть не углубляясь, первая полезней для России, так как опен сорс обычно приоритетней. Во второй много всяких облаков, которые неактуальны в РФ.
Реальные инструменты, которые используются, надо смотреть по вакансиям. Где-то будет спарк, где-то YTsaurus яндексовый, где-то просто связки питон+airflow+dbt хватит.
> По инструментам есть две ссылки платиновые:
> https://www.pracdata.io/p/open-source-data-engineering-landscape-2025
> https://mad.firstmark.com/
Большое спасибо! Буду ознакамливаться потихоньку
> Реальные инструменты, которые используются, надо смотреть по вакансиям
Ты просто описал довольно много технологий. Ты их все одновременно в течение рабочего дня используешь, или в зависимости от текущей задачи/проекта?
И можешь ещё, пожалуйста, критически оценить ответы дипсика по поводу каждой профессии? Пытаюсь остановится на чём-то одном, но как я понял из твоих слов - это +/- одно и то же и в каждой компании называется по-разному.
Просто в большинстве вакансий часто в описание добавляют что-то про аналитику, а мне это не очень нравится (общаться с заказчиком, участвовать в созвонах и писать писанину)
>Ты их все одновременно в течение рабочего дня используешь, или в зависимости от текущей задачи/проекта?
Прямо сейчас только Airflow + питон + СУБД, больше ничего. Иногда кто-то просит в эксель что-то выгрузить, для этого есть скрипты на питоне и R. Проект у меня один, так что тут сильно не разгуляться.
>как я понял из твоих слов - это +/- одно и то же и в каждой компании называется по-разному
Да, из моего опыта это всё мешают в кучу и называют или так как хотят, или так, под что уже есть готовые должностные инструкции в компании.
На твоих пиках ответы больше для западных компаний подходят как мне кажется. Полноценные devops-задачи на DE обычно не кидают, "бигдата" тоже есть не везде (а где есть, не везде нужна). SQL нужен всем без исключения.
>в большинстве вакансий часто в описание добавляют что-то про аналитику
Не, этим точно не DE занимается. В крупных компаниях есть системный аналитик для этого, в мелких есть или тимлид, или другой какой руководитель. Максимум ты будешь общаться с аналитиками данных и им подобным, которые уже знают, что им нужно (хотя некоторые, конечно, не знают).
>Буду ознакамливаться потихоньку
Это просто для кругозора, чтобы знать, какие инструменты и альтернативы под каждую задачу есть. А то многие про тот же кликхаус или duckdb вообще не слышали.
Поищи в тг роадмап для ДЕ от Жени Виндюкова, куча народу вкатилось в айтишечку благодаря нему.
Нихуя. Спасибо тебе огромное. Мне прям стало очень интересно заниматься, когда есть готовый путь.
>Писать скули может даже саппорт если припрёт
>>3400989
>Вообще скуль учится буквально за месяц, если не за недели две, по крайней мере на уровне аналитика
На самом деле это не так. Минимум полгода и это на уровне слабенького понимания как джойнятся таблицы. Про действительно сложные запросы с разбором плана планировщика и оптимизацией, плюс вьюхи и т.д включая группировки это минимум год-полтора ежедневных занятий и чтения книг с ведением конспектов
Минимум полгода ты будешь учиться писать слово SELECT, потом еще по полгода на FROM и WHERE. Надо потратить минимум 5 лет ежедневных занятий по 8 часов в день, чтобы написать селект звездочка.
В реальной разработке ты практически никогда не будешь писать обычные SELECT, FROM и WHERE. Ты будешь использовать фильтры, json'ы и кучу встроенных функций, которые нужно помнить, и озможно встраивать код на питоне
Я пишу селекты и складываю их в хранимки. У нас продуктовая система, которая ворочает терабайтами данных, а не потешный стартап-однодневка. База крутится на одной машине на MSSQL. Когда-то у нас тоже был орм, NHibernate если не ошибаюсь, но потом система стала дико тормозить на наших объемах. Пришлось выбросить нахуй все DDD говно с абстрактными абстракциями и начать писать SQL руками.
Я аналитик (бизнес и системный в одном лице), из прикладных навыков есть SQL на среднем уровне, так как периодически надо писать ad-hoc запросы, могу поправить хранимую процедуру, в которой формируется отчёт и т.п.
Бизнес и системная аналитика смертельно заебали, хочется больше вертеться с данными. Смотрю на коллег ораклистов - у всех какой-то вайб уныния, стойкое ощущение что индустрия разработки БД породнилась с какими-нибудь крестовиками, да и судя по коллегам, вижу что перектатиться на новую работу им кратно сложнее, чем какому-нибудь фронтендеру или джависту.
Собственно, вопрос - чё делать то? Ловил кто выгорание и катился с БД на другие стеки? Как будто бы логичным и наименее болезненным процессом виднеется мне перекат в ETL/DWH/Data аналитик/инженер. Если кто перекатывал - что осваивали из навыков, достаточных для миддла где-нибудь на 200к? Вижу что нужен питон, само собой SQL, git, уметь обращаться с airflow ну и девопские бонусы по типу настройки какой-нибудь grafana. Уровень про, как я понимаю - это ещё уметь наклепать отчётность в какой-нибудь BI системе.
А как DDD связано с ОРМ? Ну дергалась в коде ОРМ, теперь дергается процедура, да хоть апи, какая хуй разница?
Разница в том, что DDD - это ООП, а в ООП у тебя не может быть четверти объекта, он или весь в памяти или нет. База же работает с кортежами, если тебе надо взять юзерайди юзернейм, ты только их и берешь. База отдает их из индекса, который ты партицировал на ссд, и все летает.
В итоге у тебя или 100500 дтошек и быстрое приложение, или красивое ООП с инкапсуляцией и полный пиздец с производительностью.
я пишу селект звёздочка в реальной разработке. Ибо орм обсирается когда дело выходит дальше показа демо заказчику
>DDD - это ООП
Это разумеется не так.
Про "целость" объекта тоже какая-то хуйня написана. Тебе нужны определенные данные, чтобы сделать работу. Ты хоть ебанись, а их придется получить. То что "объект" должен по какой-то хуй пойми какой причине быть больше чем "дтошка" ты сам себе выдумал.
А самое смешное, что в DDD как раз одна из основных идей это контекст. В контексте прав "пользователь" - это буквально ID + список прав. А в контексте профиля "пользователь" - это "Имя", "Телефон" и прочая хуйня. То есть буквально одна из основных идей DDD - создавать под каждую ситуацию свой объект, в котором только нужные данные.
>100500 дтошек и быстрое приложение, или красивое ООП
Тут просто какая-то шизофазия уже пошла. А дтошки с какого хуя объектами перестали быть? И код, который с ними работает разве не в объектах? И на этот код что, все эти вредные "икапсуляции" не распространяются и там можно просто срать по настроению?
Ладно, спишем на то, что это просто то как видит приложение не программист, который только краем уха слышал про все эти аббревиатуры. Не тот тред чтобы лекции по DDD читать. Проехали.
>>3457955
А могли бы хранить всё в KV базе и не ебать себе мозги. Пиздец, ну и проблемы в этом вашем SQL кале.
А как в kv кале сделать агрегацию какую-нибудь? Посчитать сумму по периодам? А как в kv кале подтянуть к остаткам бренды и сопутку и отфильтровать товары, для которых сопутки больше, чем самого товара, но оставить бренды, проплатившие показ сопутки?
Пишешь скрипт и агрегируешь, считаешь суммы и занимаешься чем угодно ещё, ты ничем не ограничен. Можешь даже выбрать своё представление или написать трёхмерную репрезентацию, подсчитывать по любоым кривым и любым функциям. Т.к. ты всё это делаешь с максимальной эффективностью - время всех запросов раз в 30 меньше чем в SQL. Круто, да? Но тебе придётся кушать SQL кал.
Какая нахуй эффективность, если тебе приходится все данные себе в скрипт тянуть? Скачал себе пол базы, чтобы простенький аналитический запрос сделать. Ну а хули, вселенная остывает, надо подогреть.
> Скачал
Что ты там качать собрался, шизло? Бд в озу реплики находится.
Когда-нибудь ты тоже вкатишься в айти, попробуешь
>создавать под каждую ситуацию свой объект
и будешь обоссан на ревью.
> ну маам, ну скажи им что писать sql-кал это очень важно
>мам я не понимаю множества я гуманитарий че они ржут ну мам
> ну множества, мам, множества только в sql можно поститать!1 скажи им, мааам!11
Да как выучить СыКуЭль на достойном уровне, чтобы не валиться на собесах? Один книг от Джона Цэлко с десяток наберется!
Достойном уровне для чего? Бэкенда? Базовый SQL за один день учится
Есть классные книги, которые подготовят меня к написанию запросов на бекенде? Ну чтобы с джоинами, группировками и т.д? Sql for data analysis подойдет? С птичкой такая