Ссылки:
- https://www.postgresqltutorial.com/
- https://www.mysqltutorial.org/
- https://www.sqlitetutorial.net/
- https://www.oracletutorial.com/
- https://github.com/agarcialeon/awesome-database
Задачи:
- https://www.sql-ex.ru
- https://www.codewars.com/?language=sql
Продвинутый MySQL:
- https://www.mysqltutorial.org/mysql-resources.aspx
- https://shlomi-noach.github.io/awesome-mysql/
Инструменты проектирования БД
- https://www.mysql.com/products/workbench/
- https://explain.dalibo.com/
Видосики:
- Плейлисты по разным СУБД: https://www.youtube.com/c/SQLDeveloperBI/playlists
- https://www.youtube.com/playlist?list=PLY7PmJJFH5nT-lbFKxfbp3rw5BBuq5Azo
Литература:
- Томас Кайт. Oracle для профессионалов
- https://postgrespro.ru/education/books/dbtech
- Алан Бьюли. Изучаем SQL. - про MySQL
- К. Дж. Дейт. Введение в системы баз данных
Прочее:
- 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/
FAQ:
Q: Нужно ли знать английский?
A: Нет.
Q: Что лучше, SQL или NoSQL?
A: SQL.
Q: Вопросы с лабами и задачками
A: Задавай, ответят, но могут и обоссать.
Здесь мы:
- Разбираемся, почему PostgreSQL - не Oracle
- Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
- Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обеществе
- Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
- Анализируем, как работает поиск вконтакте
- И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно.
Поехали!
>юзать pure sql
Чем SQL лучше, чем NoSQL?
Какие варианты для вката есть, если ты хорошо знаешь SQL ( диалекты Postgre/Oracle и их процедурные расширения по типу PL/SQL)?
Я редко вижу вакансии database developer'ов, в основном знание SQL это дополнение к какому-либо языку программирования.
Писали, что можно с PL/SQL в банк пойти, но не по наслышке знаю, что сейчас тенденция у банков переходить на Postgre. Понятно, что процесс перехода не быстрый, но один хуй технология устаревающая, а хочется не остаться с голой жопой.
Какие варианты сейчас вообще есть? Хотелось бы, чтобы сфера была не хайповая (особенно в части вкатунов) и не умирающая.
https://hh.ru/search/vacancy?text=Pl%2Fsql+developer&from=suggest_post&area=1&hhtmFrom=main&hhtmFromLabel=vacancy_search_line
Попробуй Алана Бьюли "Изучаем SQL", там оч подробно расписана как теория бд, так и работа со всякими SQL-операторами.
Пик скорее просто конспект документации постгре с примерами, лучше с более общего чего-то начать и потом переходить к этому
Есть годные ресурсы поэтому вопросу? Или может быть гит какой-нибудь? хз даже че гуглить
Посоветуйте, как лучше реализовать хранение этих свойств товара. Т.е. я создаю имя свойства, slug для поиска и значение. Значение может быть только одного типа. Как решение нагуглил, хранить тип в одном поле, а значение текстом в другом либо использовать json или EAV. EAV слишком сложно и много усилий требуется для выборок потом через ОРМ. Насчет первых двух пока сомнения в плане производительности. Использую postgres если что.
1) Ты никуда не денешься от дилемы json vs eav. C json соснешь когда кабаныч будет от тебя требовать аналитику. Например захочет узнать какого цвета платья в этом сезоне лучше продавались. Не то чтобы невозможно, будешь костыли городить.
2) Когда ты проектируешь ключевые фичи софта, позиция "слишком сложно, давайте сделаем проще" - глупая. Сложное не может быть простым .
мое имхо
>EAV
EAV не нужен. Тебе нужна структура: товар, шаблон товара, свойства шаблона, значения конкретных свойств для конкретного товара.
Пример.
Шаблон: телевизор.
Свойства шаблона: тип матрицы, диагональ итд.
Товар: название: LG OLED65C3RLA, шаблон: телевизор.
Значения свойств товара: тип матрицы: OLED, диагональ: 65 " итд.
Обычные реляционные данные и никакого EAV'а.
Непонятно то ты предложил если не EAV. У тебя под каждый тип шаблона что ли таблица будет отдельная со своими столбцами для свойств товара или у тебя будет огромная таблица с сотнями столбцов под все свойства?
EAV как раз реляционная модель, чтобы не создавать таблицу для всех свойств всех товаров и еще иметь возможность динамически свойства добавлять.
ХЗ может я тебя неправильно понял
Когда я делал похожую штуку, я сделал очень просто: сделал дополнительную таблицу и ебнул туда 10 колонок интов, 10 строк, 10 датавремя и так далее. У нас не магазин, у нас документооборот типа джиры, и пользователи могут добавлять кастомные поля к карточкам, в зависимости от типа. Для магаза я бы сделал похоже, взял бы таблицу Metadata (ProductId,TypeId,IntValue,StringValue...) и складывал бы туда эти кастомные свойства. Запросы получаются тривиальные: AND EXISTS(SELECT 1 FROM Metadata WHERE ProductId=p.Id AND TypeId=10 AND IntValue=55) чтобы показать все телевизоры с диагональю 55.
Иными словами, классический EAV.
>EAV как раз реляционная модель
Пчел, ты вообще знаешь что такое "реляционная модель"? Что по твоему такое этот самый "realtion"?
Нужно динамическое создание свойств. Шаблон не пойдет.
>>3125246
Вот я и думаю сижу.
>>3125650
Как-то не очень эффективно, плюс искусственное ограничение на количество свойств. Я не могу сказать заранее сколько свойств понадобится какому-нибудь клиенту.
Пчел...
https://en.wikipedia.org/wiki/Relation_(database)
Relation это "отношение" данных в кортеже (row) к атрибутам (column) в таблице.
>'ID' from the domain of integers, and 'Name' and 'Address' from the domain of strings
>A predicate for this relation, using the attribute names to denote free variables, might be "Employee number ID is known as Name and lives at Address".
А в EAV все колонки таблицы сведены в одну. В базе литератруно только одна таблица с тремя колонками: Entity (id), Attribute (column name), Value (value).
А схема, которую ты нарисовал, сохраняет семантику. Именно поэтому она никакой не EAV, по ней вполне можно формировать вменяемые предикаты, в отличие от EAV'а, где у тебя и "шаблон" и "свойства" и "значения" в одной таблице находятся.
В википедии статьи пишут кукаретики, там много хуйни. Тебе анон нарисовал реальную рабочую схему.
>В википедии статьи пишут кукаретики, там много хуйни.
Ты типа новую реляционную теорию разработал или че? Или старую опроверг? Когда уже весна закончится, столько шизиков и ебанутых давно не видел.
>Тебе анон нарисовал реальную рабочую схему.
Это блядь моя схема. Ясен хуй она рабочая, она прямой сейчас в нескольких компаниях работает.
Если бы ты, хуйло слепошарое, читал тред, то увидел бы что речь шла о том что анон не понимает что такое EAV. И в чем разница между "реляционной моделью" и "EAV моделью". А чтобы это понять надо для начала знать что вообще такое "реляционная модель". И по каким "кукаретическим" принципам работает база данных, в которой тебя, обезьяну тупорылую, научили бездумно создавать таблички.
>>3125742
А, я неправильно тебя понял. Такую штуку я сам сделал изначально, с разными полями для разных типов. Не знаю как выбрать товары, у которых цвет красный и размер равен 42, например. Естественно, одним запросом нужно.
Тупанул. Можно же наделать соединений на каждый фильтр или иннер джойнами.
В чем проблема? SELECT product_id FROM values WHERE property_id=10 AND int_value=20 подразумевая, что 10 - это свойство "цвет", а 20 - "красный". Берутся эти значения из селектов на формочке, когда пользователь заполняет форму поиска.
Я бы сделал через EXISTS(SELECT 1 FROM...), так лучше читаемость. Джоины для колонок в гриде, экзисты для фильтра.
Ты тупанул в тот момент, когда вместо изучения литературы из шапки запустил жпткал. И вывалил тебе жпткал лютейшей хуйни. А если свойств будет пять, а если десять? Я про перфоманс этого дерьма даже и не говорю, просто про читаемость.
Вот так это делается https://dbfiddle.uk/1MYQQ2Ek
На индексы похуй, я хотел семантику показать. Таблицы связаны между собой в виде ромба, и начать запрос можно с любого угла, с того который выборку максимально уменьшит. А если в таблицу со значениями еще и колонку с идентификаторами шаблонов добавить, то можно будет совсем интересную аналитику делать.
Короче учи SQL, чтобы не быть баттхертом. А жптговно тебе в лучшем случае переврет какое-то рандомное говно из интернета, а в худшем просто насрет бредом.
Как удобно, когда у тебя все значения строкового типа. Изначально вопрос был, про то как хранить и выбирать значения разных типов. Нужны фильтры размер от 10 до 50, например. Булевы еще.
Лол. А зачем тебе "разные" типы? Ну вот зачем тебе INT, например? Значения это в принципе не INT. Они могут быть отрицательными? Их можно складывать/делить? Зачастую еще и единицы измерения надо как-то прикручивать.
Нахера весь этот геморрой, если все эти значения в конечном счете показываются на сайте в виде СТРОКИ? У тебя и так будет механизм, превращающий твои "булевы" значения в читабельные "Да/Нет" или "Есть/Нет".
Забыл про значения "между", "больше/меньше" и прочее.
Вот так это можно сделать прямо в SQL https://dbfiddle.uk/xRkE5wzL
Хотя обычно это делают в приложении, когда запрос составляют. Ты буквально можешь выбрать формат сравнения в зависимости от параметра.
>ведь не существует же таких джуниорских позиций
Вы заебали уже джуниорскими позициями. Они чё блять какие-то особенные? Там меньше работают, меньше требуют или чо. Они абсолютно идентичные по всему, там просто добавили слово junior в заголовке и всё. Это обычный сраный кликбейт, чтобы больше людей откликнулось.
Там меньше платят. Если сразу платить много человек выгорит даже не поработав в сфере ИТ. А так у чела будет цель к чему стремится и въебывать.
>Там меньше платят
Это вообще ничё не значит. Бывает что на вакансию с 30к зп претендует 200 человек. И наоборот, на зарплату 300к претендуют 2 человека. У нас полно долбоёбов с низкой самооценкой, готовых работать "за еду", "за хоть какие-то копейки", в надежде что набьют опыт и уйдут в другое место. Готовы унижаться, лизать пятки. Хоть там будут платить 10к в месяц, всё равно туда припрёться стадо баранов и попросит их нанять. Низкая зарплата никого не отпугивает. Даже если там будут плётками пиздить, водить в кандалах, он всё равно скажет, ну как же! Это же опыт!
Ты пиздец как недооцениваешь то, на что люди идут РАДИ ОПЫТА. Они готовы быть терпилами год-два-три, терпеть всю хуйню, низкую зп, микроменеджмент, легаси код, хуёвое отношение, неинтересные задачи, переработки, работу в праздники, лишь бы получить строчку в резюме.
>>3127547
>>3127572
Не существует джуниорских СПЕЦИАЛИЗИРОВАННЫХ позиций. Джуниор нужен когда "немного того немного этого", "ну хоть как-то", "че-то надо". Денег нет, но хоть че-то надо. Вот это работа для джуна.
А на специализированную должность нужен, внезапно, СПЕЦИАЛИСТ. И вопрос "как мне вкатиться" нужно переделать в вопрос "как мне стать специалистом". И сразу все понятно: хуй пойми как, тяжело, долго, без гарантий. И сразу всякие тупорылые катящиеся клоуны покатятся в другую сторону.
Двачую. Он пока никто, зеро. Логично, что вначале все будут отказывать. Вырастет как специалист, тогда его работодатели сами начнут приглашать на работу. Устройство на работу вначале это по сути брутфорс. После того как откажут первые 10-20-30 раз, где-то на 15-м или каком-нибудь собеседовании он устроится, если не сдастся и не съебёт в другую отрасль.
Я не об этом.
Я о том что варианты:
>Стать специалистом (Яндекс Наебтикум) -> Устроиться на спец вакансию
И
>Притвориться специалистом (наебать) -> Устроиться на спец вакансию
Это по умолчанию попытки что-то скроить и кого-то наебать (возможно самого себя).
Пикрелейтед примерный маршрут "вката" моего и людей, которые были вокруг меня. Понятно что границы условные. Но. Это я решил что красноглазая хуйня не для меня. Это я решил что sql процедуры это не то что я хочу видеть восемь часов в сутки. Это я решил что рот ебал пиксель перфект адаптивной верстки и вешать поведение на кнопочки.
И мне блядь ни на секунду в голову не приходило спрашивать в интернете как вкатиться на узкоспециализированный стек. Потому что ответ очевиден: ты открываешь резюме и устраиваешься на подходящую тебе вакансию, туда где есть интересующая тебя хуйня. Через несколько месяцев, даже просто от поглядывания со стороны и разговоров в курилке, у тебя инфа по этому стеку из носа течь будет.
А если ты предыдущий абзац осуществить не в состоянии, то охлади траханье. И поделай че попроще. Можешь конечно и "побрутфорсить" головой об стену и попытаться получить все и сразу. Если станешь тем самым одним из тысячи, то мое почтение. Только есть подозрение что людям, у которых башка на столько хорошо варит, советы долбоебов с двачей не очень нужны.
Суть вопроса была не в поиске джуниорских вакансий, а в том, что такие вакансии изначально предполагают наличие аналогичного опыта, которому непонятно откуда взяться, поскольку, опять же, не существует начальных позиций конкретно на эти спецухи.
И тут возникает вопрос: если не существует начальных позиций на эти вакансии, то откуда берутся специалисты, которые на это откликаются и находят работу? Откуда они берутся?
>если не существует начальных позиций на эти вакансии, то откуда берутся специалисты, которые на это откликаются и находят работу?
Какая разница? Работодатель описывает ИДЕАЛЬНОГО КАНДИДАТА. Если баба на сайте знакомств пишет "хочу мужика красивого, с зарплатой от 300к", откуда возьмутся красивые мужики с такой зп? То есть, работодатель может хотеть чего угодно. Вопрос в том, если придут два кандидата например и они подходят только на 70%, но того нет и сего нет. Что будет делать работодатель? Он может либо ждать ещё месяц-другой-третий, либо он будет мириться с отсутствием чего-то.
Так а че ты высрал? SQL это Structured Query Language. Ты, жирная хуйня, с каким Language его сравниваешь лучше/хуже? С джаваскриптом?
ʁ нǝ uониwɐıo ʚqı ʚɔǝ εɓǝɔq ʚоudоɔqı жоuо̯n Һиɯɐǝɯǝ иvи Һǝ
Ну вот я читаю ОП, а там написано:
>Q: Что лучше, SQL или NoSQL?
>A: SQL.
Вот я и спрашиваю, чем? Оно же там не просто так написано, правильно?
А дальше ты че не читал?
>Задавай, ответят, но могут и обоссать.
Принимай урину, спрашиватель.
>Вот я и спрашиваю, чем? Оно же там не просто так написано, правильно?
Холиварный вопрос, нельзя так сравнивать. Разных реализаций NoSQL с десяток и все они друг от друга отличаются. Если ты имеешь ввиду MongoDB, так и говори. Если CouchDB - это другой разговор. А если DynamoDB - то это третий. В одной ситуации одно лучше, а в другой ситуации другое. NoSQL практически не обладает развитым языком запросов (кроме MongoDB, у монги есть aggregation pipeline, у CouchDB mapreduce). В SQL ты не ограничен в запросах, можно хоть 5-ти этажные строить.
вот тут шмонга явно получше будет
>>3125147
>Короче делаю магазин, в котором пользователь сможет сам создавать товары и дополнительные свойства товаров (например цвет, размер и т.д.). Естественно это все нужно фильтровать в поиске.
но мы же не хотим простых решений. давайте лучше будем ебаться с EAV
Через неделю пользователь просит аналитику по продажам дилдаков красного цвета в регионе саратов и твоя монга обмякает. SQL тем и хорош, что можно писать любые запросы и крутить данные, как хочешь.
Петр Зайцев — MySQL® и MongoDB® - когда что лучше использовать?
Это такая тестовая СУБД, которую зачем-то юзают студенты и пхпшники.
а ты аналитику на oltp крутишь? ну удачи с таким подходом
Ааааа. Я-то думал этот чепух сравнивает с НАСТОЯЩЕЙ базой, которая и EAV и джейсоны умеет. Он бы еще с экселем сравнил.
Вот тебе типичная задача из этой области.
У некоторых товаров недозаполнили свойства. У некоторых телеков разъемы не прописали, у смартфонов объем памяти. Как найти все недозаполненное и оценить фронт работ для описателей, в твоей OLAP дрисне?
Схема примерная. Офк набор знаний у всех разный и требования тоже. Речь была о том что "вкат" в этой схеме происходит слева направо, в течении нескольких лет. А не в середину за три месяца, потому что где-то че-то прочитал.
вот тебе типичное решение
на OLAP дрисне я вообще нихуя не буду делать
ни на моей, ни на твоей
>один SQL запрос
>но мы же не хотим простых решений. давайте лучше будем ебаться с EAV
>простое NoSql решение
>пик с десятком говносервисов и стрелочек
Это настолько хуево, что я даже не буду предъявлять за отсутствие в посте конкретного решения. Так говно себе по губам размазывать это надо уметь.
>один SQL запрос
хахаха. ты рили веришь, что у бизнеса будет один запрос за все время?
ну если твой манямирок реально такой, то проще простого
>>3129203
>У некоторых товаров недозаполнили свойства. У некоторых телеков разъемы не прописали, у смартфонов объем памяти. Как найти все недозаполненное и оценить фронт работ для описателей, в твоей OLAP дрисне?
Шаг 1: Получение списка всех свойств
Шаг 2: Поиск товаров без всех свойств
Шаг 3: Вывод результатов
ПРОФИТ!
задаса изи. вообще при хорошем знании синтаксиса запрос пишется за 15 минут. при плохом за 30, чатжпт поможет если что. не вижу проблем
>простое NoSql решение
Самое что ни есть простое. Создал коллекцию, дал креды беку — все.
>пик с десятком говносервисов и стрелочек
А что нам не нравится? то есть делать какой-то анализ на продовой базе магазина норм, а пик не норм?
повторюсь, если приходит бизнес и говорит: нам нужна онолитега на oltp — они идут нахуй
>хахаха. ты рили веришь, что у бизнеса будет один запрос за все время?
Я про то что эта задача решается в ОДИН SQl запрос, алеша.
>ШагШагШаг
И? Кто эти шаги будет делать? Где будут храниться результаты шагов? Как пользоваться итоговым результатом?
>Получение списка всех свойств
Ты забыл слово "необходимых". Как ты будешь этот список "получать"?
>Поиск товаров без всех свойств
Ошибка. У НЕКОТОРЫХ товаров нет НЕКОТОРЫХ свойств. У товара А нет свойств 2 и 3, у товара Б 1 и 3, у товара В только 3. Свойства 3 вообще нет в датасете, смекаешь?
>задаса изи. вообще при хорошем знании синтаксиса запрос пишется за 15 минут. при плохом за 30, чатжпт поможет если что. не вижу проблем
А я не вижу запросов. Где запросы, билли?
>а пик не норм?
То что на пике это не норма. Это маняфантазия для долбоебов.
>Я про то что эта задача решается в ОДИН SQl запрос, алеша.
Петя, это ОДИН запрос в монге.
Я помню банке работал, так там отчет формировался тоже за ОДИН SQl запрос. Правда в нем было около 1800 строк, но запрос был ОДИН
>И? Кто эти шаги будет делать?
кому надо тот и будет делать
>Где будут храниться результаты шагов? Как пользоваться итоговым результатом?
на сервере естессно. по ccш подключаешься и смотришь в консольке. причем пот рутом. нужно только onoliteka.rar расспаковать
че неудобно? ну а хуйли ты хотел? какие требования — такой и результат
>Ты забыл слово "необходимых". Как ты будешь этот список "получать"?
охуеть какая сложная задача!
в пострес же нельзя узнать имена всем существующих колонок в бд
>Ошибка. У НЕКОТОРЫХ товаров нет НЕКОТОРЫХ свойств. У товара А нет свойств 2 и 3, у товара Б 1 и 3, у товара В только 3. Свойства 3 вообще нет в датасете, смекаешь?
Это ты только что узнал как документы в коллекциях хранятся?
>А я не вижу запросов. Где запросы, билли?
>То что на пике это не норма. Это маняфантазия для долбоебов.
Как и аналитика на проде. Поэтому в очередной раз для самых самых тупых поторяю — с такими запросами вы идете нахуй
сделать аналитику на проде? а может сразу модели нейросетей крутить?
>это ОДИН запрос в монге
Ну так где он? Пуки вижу, запроса не вижу.
>нужно только onoliteka.rar расспаковать
А с SQL не нужно.
>Как ты будешь этот список "получать"?
>пук
Весомо. Аргументированно.
Дегенерат, ты так и будешь пердеть в тред? Ты либо пруфаешь конкретными запросами и результатами, что на монге-хуенге эту задачу сделать вообще возможно, либо сглатываешь. Все твои охуительные истории про какие-то выдуманные банки, про хуйню и малафью никому не интересны. Своим протыклассникам будешь эту лечку гнать. А тут без реального кода, ты так и останешься вечно обоссанным пиздливым nosql попущем.
в очередной раз для самых самых тупых повторяю — с такими запросами вы идете нахуй
Ну обосрался. Обосрался же? Обосрался. Нахуя дальше на себя то ссать?
Ну так и скажи: не ебу я как это делается в монге, пизданул не подумав, проблематику не знаю, думал оно лучше, да походу нет.
Почему каждый раз так: прибегает очередная nosql маня, ррякает и верещит как же все там заебись, а когда её просят решить малейшую прикладную задачу, мгновенно сливается.
Ну бквально же итт:
>вот задача, вот так она решается на SQL
>а на nosql все это легче и быстрее
>покажи
>пошел нахуй
Стронгли пруфд ноускьюл супериорити. Не снимая штанов, как грится.
У меня вообще-то основная специальность MSSQL и Databricks. Но там где проще использовать NoSQL, я конечно использую MongoDB или Redis или еще что-нить. А иногда тупо parquet в s3 складываешь. А где надо реляционку, то могу и PostgreSQL или MySQL. Но MSSQL — это топ для меня конечно, но не для нищебродов.
Только полные дауны используют один инструмент для всего как серебряную пулю. Поэтому если ты зациклился на сукили и не можешь такой запрос написать для монги — поздравляю, ты обосрался. Причем конкретно. Не нужно свою узколобость пытаться выдать за выдающие знания в БД.
А если ты думаешь, то я по первому твоему кличу побегу писать тебе запросики — ты не просто даун, а полный даун. Поэтому еще раз — иди нахуй.
>прибегает очередная nosql маня, ррякает и верещит как же все там заебись, а когда её просят решить малейшую прикладную задачу, мгновенно сливается.
Лох подорвался, с пеной у рта чёто там доказывает. Успокойте шизика, дайте ему таблетки. А то он горящим пердаком спалит всю хату.
>Через неделю пользователь просит аналитику по продажам дилдаков красного цвета в регионе саратов и твоя монга обмякает
На ---> https://pastebin.com/GfWZ2HG5 а то у тебя пердачелло сгорит ещё больше. Это пример аналитики по продажам в монге.
>бесконечная стена write-only джейсона вместо 10 понятных строк на sql
Все-таки использование джаваскрипта и производных приводит к органическим поражениям головного мозга. Что в коде, что в запросах.
>А если ты думаешь, то я по первому твоему кличу побегу писать тебе запросики
Нахуя мне, ты напиши тому анону, которому ты влечивал какая монга в этих задачах охуенная. Я-то ему и "запросики" дал, и что таоке EAV объяснил. Потому что это легко и просто, дело десяти минут.
А ты бегаешь по треду с порванной жопой, хотя мог просто на чилле запостить "легкий и простой" запрос в монгу и закрыть вопрос. А ты чего только не высрал: и "я важный, хуй бумажный", и "мне вас жаль", и "я ничего никому не должен". Платина за платиной.
Так ему не надо. Это у тебя фантазии поскакать на скакать на красных дилдаках в Саратове.
Ну тогда фиксируем очередной отсос адептов монги и расходимся.
фискирую отсос узколобых даунов, которые не могут в информационные технологии, но любят красные дилдаки
>Вот как жта проблема решается на sql
>на монге можно лучше
>покажи, научи
>пошли нахуй, узколобые дауны
Как называется эта болезнь?
>аноны мне нужно хранить объекты без схемы данных, какое просто решение?
> MongoDB или аналогичные
>не подходит, вдруг попросят аналитику, а я в разработке не шарю, поэтому не могу продумать и создать оптимальное технологичное решение, зато я умею кодить на SQL и могу на проде крутить запросы
Как называется эта болезнь?
КОго ты пытаешься наебать?
>аноны мне нужно хранить объекты без схемы данных, какое просто решение?
> MongoDB или аналогичные
>А ОНО ПОДХОДИТ? Вот так можно?
>АРРЯЯ иди нахуй
> напиши запрос на проде
> иди на хуй. прод не для этого
> ну а ты напиши
Как называется эта болезнь?
>А ОНО ПОДХОДИТ? Вот так можно?
А твоя реляционка может обрабатывать петабайты данных и крутить модели нейросетей?
>>3129203
>Вот тебе типичная задача из этой области.
Нужно показывать рекомендации которые посетитель магазина захочет купить. Причём модель должна дообучаться прямо в онлайне. Как это сделать в твоей дрисне?
>и фейсбук
Ну то есть тысяча человек?
А знаешь почему в фейсбуке до сих пор эта дрисня? Потому что она нихуя не следует стандартам и с неё невозможно слезть даже на "такое же но лучше".
Пикрелейтед главные долбоебы индустрии поняли в каком они теперь дерьме
https://www.uber.com/blog/mysql-to-myrocks-migration-in-uber-distributed-datastores/
А могли бы на постгресе с кайфом сидеть, там за это время семь мажорных версий сменилось.
Ты имеешь в виду и монгу и постгрес?
Никто не мешает. Тем более сейчас, когда все в контейнерах.
Тут все зависит от команды на самом деле.
Если у тебя в команде только старперы, которые ничего нового не хотят, но зато умеют хорошо кодить на sql — они будут использовать только реляционку.
Я когда н-цать лет назад пришел в одну контору, так у них все было в бд сделано. То есть схема была вебморда <-> бд. Вся бизнес-логика, весь бэк и все прочее было реализовано функциями и процедурами в СУБД.
Если в команде есть архитектор или просто кто-то вменяемы с мозгами, то будут использовать подходящие технологии под каждый сервис
>Ну то есть тысяча человек?
ну то есть топ-3 посещаемый сайт в мире
>там за это время семь мажорных версий сменилось
да хоть пятьсот. как это помогает решать бизнес задачу? у нас некоторые сервисы до сих пор на 9 крутятся
>ну то есть топ-3 посещаемый сайт в мире
Он что ставит каждому посетителю mysql и заставляет этим говном пользоваться?
>да хоть пятьсот. как это помогает решать бизнес задачу? у нас некоторые сервисы до сих пор на 9 крутятся
А у меня тетя тридцать лет все в блокнот ручкой пишет. Стабильная тема, переводите свои сервисы с постгри на блокноты?
как будто ты каждому пользователю ставишь свои мажорные версии
у тебя есть приложение банка, личный кабинет какой-нить, сайт жкх, да хоть игрулька какая-нить?
зайди к ним на сайт или в приложении посмотри чейнджлог
там нихуя не будет про мажорные версии бд — всем похуй
по популярности в интернете (посты, линкедин, вакансии etc) монго не далеко от постгрес, но даже в сумме они не дотягивают до мускуля
>Ну то есть тысяча человек?
если для тебя это важно, тогда используй монгу. там доля рынка гораздо больше, чем у постгрес
А оракл на первом месте тебя конечно не смутил?
>Number of mentions of the system on websites
>searches in Google Trends
Вот вся статистика, которую нужно знать
https://survey.stackoverflow.co/2023/#most-popular-technologies-database-prof
https://survey.stackoverflow.co/2022/#most-popular-technologies-database-prof
https://survey.stackoverflow.co/2021/#most-popular-technologies-database
https://survey.stackoverflow.co/2020/#technology-databases
Мускуль и монга на дно, постгрес стабильно растет и пару лет назад занял первое место.
Но самый цимес это разница между профессиональными голосами и голосами "вкатунов".
Мускуль: вкатуны 58.40%/профи 45.68%, постгрес: вкатуны 25.54%/профи 46.48%, монга вкатуны 31.32%/профи 28.29%
То есть приличная часть тренда сформирована людьми в технологиях нихуя не понимающих. И как только они матереют и видят реальную картину - они сразу откалываются.
Кстати, оракл по опросам реальных людей, всего 10%. Как так, гугл тренды жи?
>Вот вся статистика, которую нужно знать
Не нужно. Все эти тренды это просто запросы в Google либо на stackoverflow. Поэтому неудивительно что по мускулю и постгрес так много вопросов и поэтому они в тренде. Все они являются вкатунами-нищебродами топящими за что-то бесплатное, в котором нихуя не разбираются. Поэтому приходится идти в Google либо на stackoverflow и спрашивать как это починять и таким образом генерировать тренд популярности.
Как только они матереют, то сразу переходят на что-то серьезное типа скл сервер или оракла. И так как они уже профи, то вопросов задают мало и эти субд в тренды не попадают. К тому же появляются мозги и понимают, что нет универсального инструмента, поэтому где-то нужно использовать редис монгу кафку или даже хадуп с айсбергом. Никто с мозгами конечно не будет проводить онолитеку продаж на продовой бд. для этого есть двх и би инстументы типа табло. Или Яндекс.Метрику или Google Analytics где можно крутить вертеть смотреть воронку продаж
Может сначала читать, а потом пиздеть? Это результат опроса. survey в начале ссылки тебе ни о чем не говорит? Конкретных людей спрашивали: с чем вы работаете, с чем хотели бы работать.
Дальнейшие твои фантазии на тему просто бессмысленны, потому что ты еще на этапе предпосылки обосрался.
>Это результат опроса
>результат опроса
>опроса
Опросил своих домочадцев и питомцев и по результатам этого опросы ты хуесос и говноед.
Сорри, но это результаты опроса, а с ними не поспоришь.
Я вот работаю с MSSQL еще с тех пор, когда он не был MSSQL. С MongoDB лет десять. По паре лет с DinamoDB, Neo4j, InfluxDB.
Но я не участвовал в этом опросе.
Более того, в Сбербанке больше ораклистов, чем ты наберешь участников этого опроса со всего двача.
>SQLite 3 место
Ахахаха. Сериусли?
А ты вообще прочитал что я написал?
Вкатуны, нищеебы и мобильщики идут на stackoverflow спрашивать про свою попаболь и участвуют во всяких опросах, пока серьезные дяди разрабатывают решения на Oracle или MSSQL или даже DB2, это древнее дерьмо кажется в любом топ10 банке, которые сейчас двигают весь ИТ прогресс в рaщке.
Эскуэлайт третье место. Бля, по моему это мем года
Пчел, ну и че ты высрал?
Получилось три варианта:
>рейтинг по гугл трендам
>рейтинг по опросам программистов
>мнение долбоеба с двача
Ты можешь сколько угодно угорать над опросами, но мнение анонимного хуесоса из двачерской клоаки стоит ниже любых гугл трендов.
Да лучше базу по чиркашам на унитазе выбирать, чем слушать таких дегенератов, как ты.
А чем мнение анонимного хуесоса из двачерской клоаки отличается от мнения анонимного хуесоса из стековерфошной клоаки?
а ну да ну да. там же великие погромисты сидят. типа такого https://ru.stackoverflow.com/questions/1563867/%d0%92%d0%be%d0%bf%d1%80%d0%be%d1%81-%d0%bf%d0%be-sql-%d0%bf%d0%be%d0%b8%d1%81%d0%ba-%d0%b7%d0%bd%d0%b0%d1%87%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b2%d0%be-%d0%b2%d1%82%d0%be%d1%80%d0%be%d0%b9-%d1%82%d0%b0%d0%b1%d0%bb%d0%b8%d1%86%d0%b5-%d0%bf%d0%be-%d0%b7%d0%bd%d0%b0%d1%87%d0%b5%d0%bd%d0%b8%d1%8e-%d0%b8%d0%b7-%d0%bf%d0%b5%d1%80%d0%b2%d0%be%d0%b9
>Ты можешь сколько угодно угорать над опросами
На каурсере есть курс по дата кволити (советую пройти весь). Там как раз в первой части рассказывают как можно создавать предвзятые опросы, чтобы склонить опрашиваемых в нужную сторону. Например:
Есть пять варианта:
>мнение долбоебов которые гуглят "как найти красные дилдоки в монге"
>мнение долбоебов со стековерфоу, которые из вима выйти не могут
>мнение долбоебов с двача
>мнение русских реперов
>исследование Gartner реального рынка
Ты за какой вариант?
>Я вот работаю с MSSQL еще с тех пор, когда он не был MSSQL.
При Горбачеве что ли? Пиздишь. Первая версия Microsoft SQL Server 1.0 вышла в 1988 году и была совместимой с Sybase SQL Server, выпущенном годом ранее.
Из местных кодеров самый старый Алексей Скуфьин, но даже ему в 1988 было всего всего 15 лет. Несовершеннолетних программистов в СССР на работу не брали.
NoSQL это высер маркетологов, который технический специалист употреблять не должен. Есть базы реляционные и нереляционные (документные, кэши "ключ-значение", графовые и т.д.).
Программистишки поняли, что хранить комменты из гостевухи или чата в реляционной БД не самая лучшая идея и создали специальные базы вроде Mongo для этого.
Но исторически реляционные базы появились позже нереляционных.
>вышла в 1988 году
Ага вышла и сразу у всех в проде моментально оказалось причем даже даже в совке
сразу видно что ты зеленый и даже не представляешь какой был интернет и как вообще работали в ИТ в нулевых, не говоря уже про модемный интернет и 90-ые
короч, в нулевых в рф было полно Sybase
кубернетисов не было. вообще виртуализации не было (на проде лет через 3-5 начали только внедрять)
ты покупаешь дорогущий здоровеннный мейнфрейм от IBM и там у тебя будет либо Sybase либо db2
оракл юзали для второстепенных сервисов как сейчас постгрес
>Я вот работаю с MSSQL еще с тех пор, когда он не был MSSQL.
Обосрался - обтекай, долбоеб. Мне твои оправдания неинтересны.
так обосрался тут только ты, который вкатился в IT пару лет и знает только SQL
Обосрался прямо тебе в ротик мелкобуква, иди под струю мойся.
2) Во время запроса всё таблицы базы данных загружаются в память? А не приведет ли это к нехватке памяти, если там огромные таблицы?
1) Очевидно нет, это же не redis и не memcached.
2) Загружается кеш, а не вся таблица. Размер query cache'а можно тонко регулировать в конфигах. Там много тонких настроек, от количества открытых файлов до innodb размера буфера, размер временных таблиц, размер логов и т.д.
Ну короче! Это всё регулируется через my.cnf в зависимости от ресурсов сервера, подгоняется под машину. Если ты слишком много чего-то укажешь, например 2 гб кеша а памяти только 1 гб, он либо уйдёт в swap, либо просто завершится и не будет работать. У innodb по-моему минималка 1 гб, но это не точно.
Уже пытался отвечать повышенное время отклика, тупеж параллельных вопросов да и хз что еще, тут ответ походу конкретный, но по ощущениям это морской бой догадками)
Сорян если дублирую вопрос из одного треда в тред
Что за вопрос вообще такой уебанский? "бд с низким потреблением"
Как БД блядь может быть с низким потреблением? У бд кеш либо есть, либо нет. А если есть, то его размер настраивается.
Особенность может быть у запросов, которые "потребляют мало кеша". Если у тебя десять записей в таблице, а в кеше только три, то это "низкое потребление" вызвано повторением одних и тех же запросов, между прочим для этого кеш и придуман.
А если у тебя миллиард записей и на каждый запрос выбирается случайная, то у тебя к нагрузке на диск и проц добавляется куча мусора в памяти и затраты на поиск в этой куче того, чего там нет.
>Что за вопрос вообще такой уебанский? "бд с низким потреблением"
Не мой вопрос, не я задаю тут правила
Usage count кэша маленький
Главное свойство спрашивается
>Не мой вопрос
Да ладна. Бессмысленной хуйней он от этого быть не перестает. Так что либо спрашивал долбоеб, либо ты все переврал.
>Usage count кэша
Опять какая-то хуйня. Нет такого термина "usage count". Что это блядь вообще должно означать? "Маленькое использование" кем? Тем кто сохраняет в кеш или тем кто достает? Ты понимаешь что это полностью противоположные ситуации?
Короче. "бд с низким потреблением", "Usage count" это тарабарщина. Если ты ДЕЙСТВИТЕЛЬНО на собесе это услышал, то тебя просто завалили хуйней, тебе туда не надо. А если ты сам это придумал, то новости печальные - ты профнепригоден, надо доучиваться.
Я прихожу на пересдачу уже третий раз и мне уже абсолютно поебать на формулировки этого препода.
Изначально вопрос звучал так: "В некой бд usage count буферного кэша низкий, чем она отличается от бд с нормальным использованием буферного кэша?"
На просьбу "повторите вопрос пожалуйста" ответ "а я забыл / а ты че не запомнил / надо было записывать". Уточняющие вопросы по вопросу идут туда же.
Я никогда по-хорошему не работал с бд, usage count скорее всего указывает на число записей в кэш или к числу обращений к кэшу, я думаю, что скорее первое. Условие в том, что абстрактная бд довольно мало использует буферный кэш и в этих условиях мне нужно отвтетить, какое её главное свойство.
Мои догадки:
1. Данные почти всегда свежие
2. Возможно, кэшировали индексы и поэтому такой низкий usage count, что бы это не значило
3. Т.к. бд почти всегда обращается к тейблам и объектам, то несоответствие данных почти исключено
4. Какая-то неведомая "оптимизация" через три пизды, которая на внятный ответ не похожа
Другой вопрос: "Критерии базы данных", мне хотяб на это ответить.
>2) Загружается кеш, а не вся таблица. Размер query cache'а можно тонко регулировать в конфигах.
Регулировать можно размер innodb page cache.
А query cache - средство для оживления всяких drupal-ов. Отдельная и несколько штука.
Насколько спорная, что в mysql 8 ее попытались выпилить, но в mariadb понимают что проекты бывают разные.
Причем, все это не отменяет кеш ОС.
>А не приведет ли это к нехватке памяти, если там огромные таблицы?
инвалидация кеша ОС считается бесплатной. Настолько, что он есть, но в linux программы top не показывают этот кеш.
А вот innodb page cache надо как-то подбирать экспериментально под свою нагрузку.
Куда в mariadb проебали настройку innodb_dedicated_server я понятия не имею, но ты ознакомься с документацией от Oracle Mysql
usage count ничего не означает. Есть термин "cache hit rate". Это отношение количества запросов удовлетворенных кешем к общему количеству.
Догадки твои - это не догадки, а такой же информационный шум, как и вопрос. С тем же успехом препод мог тебя спросить: хуй сосал, селедкой пахло? А потом сказать что: хуесосам незачет.
Не сходить ли тебе нахуй? Вместо того, чтобы хоть что-то предположить, рассматривая обе версии, что значит то или иное, ты просто срешь в переполненный унитаз, в результате чего твоя жопа и ноги в том же говне. Ты сюда пришел показать умственное превосходство или кому-то помочь, с тем же успехом ты можешь устроиться на линию доверия и вместо помощи человеку направлять его на суицид. Крч, ты не меньший долбоеб, чем я и препод, задающий мне эти вопросы.
> В чем особенность бд с низким потреблением буферного кэша?
такого общепринятого термина нет.
препод проверяет слушал ли ты его вообще - какую-то свою теорию создал
не совсем понятно это кеш записи или чтения.
Допустим, ситуация с большим буфером записи и отложенной записью считается нетипичной для субд и ее исключаем.
Тогда остается чтение. Субд мало повторно читает.
Теоретики делят СУБД по характеру использования на OLTP и OLAP. Описанное характерно для OLAP.
>Ты сюда пришел показать умственное превосходство или кому-то помочь,
А я всегда и прихожу показать умственное превосходство.
Просто в данной ситуации мне нравится удовольствие от того, что я понял пусть даже немного шизоидные мысли какого-то левого препода.
Помочь - никогда.
Пчел, еще раз.
Препод тебя спрашивает: хуй сосал, селедкой пахло? КОгда ты пытаешься спрыгнуть, говорит: отвечать да или нет. А после твоего ответа: хуесосам незачет.
Твои действия? Ты идешь на двач спрашивать пахнет ли хуй селедкой?
Ни то, ни другое, я схожу с ума, я нихуя не понимаю и знаю, что у него есть какой-то конченый ответ, вокруг которого я ходил на протяжении пяти часов.
На вопрос "Как реализовать шардирование в базовом постгре" ответом было "partitioning". -_-
Ответ такой же конченый, как и вопрос
Шардирование делается на уровне кода, бд про это не знает.
Партиции делаются внутри бд, код про это не знает.
Твой препод долбоеб. Ты, случайно, не в епаме курсы проходишь?
Догадка, что мы много пишем мало читаем верна и от этого кэш маленький, следующий вопрос: "что нам говорит о бд то, что у нас много записи мало чтения?"
Мысль, что это транзакционная бд, отклонена >.<
>что нам говорит о бд то, что у нас много записи мало чтения?
Это не база, это лог.
Как лучше поступить:
1) Завести 2 таблицы: одна хранит только текст, другая информацию о тексте (название, размер и т.д.);
2) Хранить все в одной таблице.
Гугли у постгреса TOAST, эха хуйня делается автоматически на уровне СУБД. С какой целью ты хочешь делать на уровне приложения две таблицы - непонятно
Храни в еластик серче. Бонусом получишь, что по тексту искать можно будет.
>>3126874
Спасибо. Сделал CTE с желаемыми свойствами, к ним соединил свои свойства, сгруппировал по id продукта количество соединенных свойств и сделал HAVING количество свойств = количество фильтров, чтобы отобрать только те продукты, которые подходят по всем фильтрам. К этой уже таблице соединил продукты. Вроде заебись получилось.
Проблему с разными типами решил через jsonb поле, которое хранит примитивные типы. Со стороны ORM даже нет разницы json там или нет.
Тебе жи все показали >>3126943 https://dbfiddle.uk/xRkE5wzL
У тя подсчет количества пройденных фильтров бисплатный, пушо все равно дистинкт делается. И подсчет количества заданных фильтров бисплатный, пушо они в cte лежат, да и сколько там этих фильтров? Десять? Двадцать? А найденных товаров может быть десятки тысяч.
"Если текстовые файлы, которые нужно прочитать, находятся на сервере, то из соображений безопасности эти файлы должны либо размещаться в директории базы данных, либо быть доступными для чтения всем пользователям."
Куда класть файл-то?
Я даже не ебу куда mysql сохраняет файлы существующих БД.
У меня нет никаких папок data.
> Куда класть файл-то?
Для начала надо решить, насколько тебе важно держать в базе данных логику, а не собственно данные, и точно ли нельзя никак обойтись без этого. Обычно этим должно заниматься приложение, разве что у тебя какой-то особый кейс с аналитикой.
> Я даже не ебу куда mysql сохраняет файлы существующих БД.
Значит, надо узнать. Копай дальше документацию.
>"Если текстовые файлы, которые нужно прочитать, находятся на сервере
Это оптимизация на спичках.
Просто не используй load data local, а загружай через клиент
Имеется ввиду, что есть возможность заставить сервер читать файл и в этой ситуации загрузка еще более оптимизирована чем обычно, но тебе это не надо.
суп
помоги нубоэникею.
установил это
установил dbeaver
даже сделал это
https://qna.habr.com/q/1110078
когда создаю сервер то ругается
чо делать плз помогите.
отдельно скажу
http://127.0.0.1 ввожу в браузере и нифига
У тебя сам постгрескл на локалхосте есть или ты просто установил pgadmin?
pgadmin - это клиент к постгресу
Браузер открывает 80-й порт, а постгрес у тебя на 5432.
Проверь, запущена ли служба (в Windows Администрирование, Службы, в Linux - через systemctl).
Проверь подключение через psql.
Установка на Windows: https://docs.rkeeper.ru/rk7/7.7.0/ru/ustanovka-postgresql-na-windows-29421153.html
Установка в Ubuntu: https://selectel.ru/blog/tutorials/how-to-install-and-use-postgresql-on-ubuntu-20-04/
Проверь все шаги, обрати внимание на порт, имя юзера и пароль. Для работы с БД сервер должен быть запущен.
сделал ровно то же самое. за одним исключением: я все галочки за раз прожимал, в статье они по одному прожимались с дровами. установил один драйвер. малаца. запусти заново. выбери вторую. repeatx2
и базу пустую создал. после этого ругаться перестало на базу. так понял, на локальном компе есть и база, и сервер.
только вот 1с сервер говорит: нету
И в строке браузера тоже ввожу, ничего.
Как серверу имя присвоить, чтобы введя в 1с его имя, или ip компа можно было базу подключать?
>>3138056
в целом, помогло, вы няши. но есть но. он ругается на кодировку при создании базы.
нужно выбирать вместо РУССКИЙ ЯЗЫК (РРОССИЯ) просто РУССКИЙ ЯЗЫК.
но третья проблема: хасп ключ красный есть, а он не действует вроде как на сервер. сервер 1с локальный ругается, что ключа нет.
>Вот тебе типичная задача из этой области.
>У некоторых товаров недозаполнили свойства. У некоторых телеков разъемы не прописали, у смартфонов объем памяти. Как найти все недозаполненное и оценить фронт работ для описателей, в твоей OLAP дрисне?
Это не типичная задача, а какая-то двачерская маня хуета. Зачем это вообще нужно? Никто такой хуетой заниматься не будет
Я вообще не понимаю о чем спор. Как будто некоторые люди где-то в начале 10-го годов остались и пилят какой-нибудь говно магазин на джумле с одной единственной базой, в которой и структура сайта хранится, и складской учёт ведётся, и продажи, и аналитика, и вообще все.
У нас бизнес по оптовым продажам для b2b. Клиентов дай бог 3000 наберётся. Сайт работает на MongoDB, бэкенд сервисы на PostgreSQL, вся аналитика на Clickhouse.
>>3143503
Ноу щит, шерлоки.
>>3143632
Просто задача с sql-ex.ru, они там с 2003 года, я помню эту схему с полетами. Если кто-то платит за это, мои соболезнования.
>В SQL ты не ограничен в запросах, можно хоть 5-ти этажные строить
А зачем? Есть какие-то бизнес-кейсы? На практике какие-то сложные и многосоставные запросы - это большая редкость. Тот же функционал монги и ORM для реляционок покрывает все потребности
SELECT
first_name,
last_name surname
FROM customer;
надо перед двачерами похвастаться какой он офигенный сукили-кодер
Портянки запросов в бизнесе как раз востребованы, чел. Я тебе говорю как сменивший 5 работ.
мимо шел
Вот тебе задача, монгошиз: нужно сгруппировать таблицу и выдать первые пять записей из каждой группы.
>Есть какие-то бизнес-кейсы?
Конечно, это в основном какие-то отчёты
> Тот же функционал монги и ORM для реляционок покрывает все потребности
Реляционка тебе все равно нужна будет, если у тебя будут транзакции, а у большинства бизнесов они есть. А дальше - значем тебе 2 базы данных, когда можно обойтись одной? Шах и мат.
маня задача с собеса?
В реальной жизни такой хуйней никто не страдает.
>>3146175
Я только за последние полтора года пять проектов сменил.
Бизнесу глубоко похуй у тебя портянка запрос или три строчки.
Они хотят какую-то реальную задачу решить.
Кто-то эти задачи решает портянками.
А потом компания вырастает, и твои портянки начинают разъезжаться
Вроде бы один и тот же отчёт, просто в разных разрезах, но показывает разные цифры
Начинаешь проводить аудит, а там какой-то потяношиз нахуячил говна на 3к строк
Привет
>маня задача
Задача типичная. Классика жанра.
Но это ведь не важно, правда? Потому что никто тебя, долбоеба, не спрашивал про степень маманястости задачи. Тебя спросили: можешь ли такое решить с помощью монги? Судя по пустопорожним кукарекам - не можешь.
Ну что, переходим к этапу "я никому не должен ничего решать, аррря"?
>>3146424
>А дальше - значем тебе 2 базы данных, когда можно обойтись одной? Шах и мат.
Под себя серешь. принёс картинку с сайта крупного ритейла. У них там зоопарк sql+nosql решений.
Кстати у меня вот тоже картинка есть. А дальше что? Под капотом сайта что работает? А запросы кто формирует? Вряд ли при каждом переходе страницы сидит кодер на sql и пишел свой скрипт
>Задача типичная.
Нетипичная. Потому что тут вся сложность не в группировки и сортировке, а десятках джойнов, так как это все в разных таблицах храниться. С учётом того что в монге все это хранится в одной коллекции, запрос будет все две строчки: группировка и слайс
>Тебя спросили: можешь ли такое решить с помощью монги?
Да, делал абсолютно аналогичную задачу. нужно было взять все продажи за час по разным категории и взять топ 10 в каждой. Делал все это на бэке через ORM
>запрос будет все две строчки: группировка и слайс
Где запрос? Так-то пиздеть не мешки ворочать, я вот точно говорю что запрос будет в джва слова: слайсировка и хуйс. Верим?
>Где запрос?
Так и где же? Весь тред уже засрал как ты на sql можешь и это написать и то написать и сё то же. А по факту ни одной строчки
>У них там зоопарк sql+nosql решений.
Это не значит что оно там нужно. Вероятнее всего это какой-то такой же кодерок решил показать какой он умный и нахуярил всех технологий, которые на конференции услышал.
Я так же видел зоопарк sql + nosql на одностраничном складе фотографий.
Регулярно помогаю анонам в этом треде с запросами. Вот это я писал, например: https://dbfiddle.uk/xRkE5wzL
Я знаю как минимум три способа решения этой задачи на SQL. И все они за рамками автосгенеренных ОРМ крудов. Мне просто было интересно как эту простейшую задачу решит монгохуесос. Судя по всему никак не решит. Потому что он похоже и не монгохуесос вовсе, а просто шизик, который эту монгу в глаза не видел.
>Делал все это на бэке через ORM
Это кинец
Гонять сотни мегабайт по сети только чтобы протолкнуть своё хипстерковое решение - это просто вершина тупизма :(
Я даже не знаю почему компании ведутся на такую хуйню. Ведь можно нанять одного базиста + одного бекендера + одного фронтендера + одного мобильщика. ВСЁ!
На хуя компания такой огромный и раздутый штат айтишников? Ведь одной базы и одного сайта достаточно для любых нужд.
>>3146894
>Гонять сотни мегабайт
А почему не триллионы? Ты вообще знаешь как ORM работает?
>>3146892
>Я знаю как минимум три способа решения этой задачи на SQL
Ты про манязадачу с двача или про типичную задачу реального бизнеса?
Если про типично реальную задачу тогда берём вот такую функциональность >>3146712
Тебе нужно вывести на сайт топ пять товаров из трех самых популярых категорий этого пользователя или этого города, если незалогинен. База данных нормализована. Плюс нужно проверить остатки на складе. Ты же не будешь как долбоёб предлагать товар на главной странице которого уже нет. Цены динамические зависит от устройства пользователя, города, категории клиента, время года, суммы его покупок за год. Скидки и бонусов подтягивается через api сервиса СЛК (Сервил лояльности клиентов)
жду хотя бы одного решения
>А почему не триллионы? Ты вообще знаешь как ORM работает?
Я-то знаю, ты похоже не знаешь, раз качаешь весь датасет к себе на бэк. Причем тут вообще ОРМ? От него ни холодно ни жарко.
>Я даже не знаю почему компании ведутся на такую хуйню.
Потому что на конференции сказали, очевидно же. После эпидемии микросервисов об этом даже глупо спрашивать.
>Я-то знаю, ты похоже не знаешь, раз качаешь весь датасет к себе на бэк
Вся база качается сразу. Чтобы два раза не ходить
Монгошизохуесос.
Все что ты тут пытался навалить ПРЕДРАСЧИТЫВАЕТСЯ специальными сервисами. Долбоебу понятно что вычислять все это говно по запросу пользователя тупорылейшее занятие. Так вот после всех этих вычислений остатков и хуятков, у тебя получается таблица с товарами, которые гарантированно можно показать клиентам. И их блядь больше пяти, а показать нужно по пять в каждой категории.
И ты пол треда срешь какой-то хуйней, но никак все не можешь высрать простейший запрос, который возьмет твои джейсончики в монге, сгруппирует и выведет по N записей в каждой группе.
Ты весь тред засрал уже, а реальные задачи для бизнеса так и не решил.
Какая-то двачерская маняхуета. Нахуй это бизнесу нужно? Ебать ты Даун конечно. Или ты просто кичишься своим знанием sql? Ну так семь INNER JOIN написать любой студент первого курса сможет. Стажеры Дата аналитики и то лучше запросы пишут.
>ПРЕДРАСЧИТЫВАЕТСЯ специальными сервисами
А то мы речь, хуесос.
Я ведь не монгошизохуесос, чтобы как тупой еблан всё делать на монге.
И не постгресошизохуесос, чтобы как тупой еблан всё делать на постргрес.
>Цены динамические зависит от устройства пользователя, города, категории клиента, время года, суммы его покупок за год.
Ну вот, а ты говорил для многоэтажных запросов бизнескейсов нет, а сам описываешь
>пук
Без запроса твоя шиза скипается. Кому нахуй интересно читать твои оправдания твоей криворукости и тупизны.
Ну если у тебя 100 пользователей в твоем онлайн магазине, то в принципе нормально. Иначе при десятках а тем более сотнях тысяч пользователи они будут заходить на сайт и ждать несколько секунд пока твои цены рассчитаются при каждом переходе на новую страницу. тут нужен распределенный key-value чтобы в оперативке все считать — по опыту могу сказать что Ignite отлично справляется с этим. либо какой-нибудь ml решение, ну это тоже не про реляционку. Суть примера в том что ни одна БД в вакууме решает проблему бизнеса. Ни монго ни постгрес ни любая другая.
Но для манязадачки с собесов в принципе пойдет.
>распределенный key-value
>либо какой-нибудь ml решение
>либо
Пиздец, прямо блядь две альтернативы.
Какое мл решение, чушпан? Ты там совсем ебанулся? С каких пор "ml решение" более быстрое или более распределенное?
Бля с каждым твоим постом все более убеждаюсь что ты просто пациент дурки, который рекламы курсов обчитался.
Плохо когда ты постгресошизохуесос и нихуя в технологиях не разбираешься, да?
Иди дальше пиши свое говно по группировке таблицы и выдаче первых пять записей из каждой группы.
>распределенный key-value
>чтобы в оперативке все считать
Чел, если ты в оперативке считаешь, то твой кейвалью не распределённый, он в твоей оперативке. А распихал по микросервисам ты его потому что "распределенный" звучит круто.
>чтобы в оперативке все считать
тогда тебе ничего не мешает выгружать датасет в оперативный кэш из обычного SQL
>Чел, если ты в оперативке считаешь, то твой кейвалью не распределённый, он в твоей оперативке
Охуеть! Неужели?
>>3146964
>тогда тебе ничего не мешает выгружать датасет в оперативный кэш из обычного SQL
Мешает. Данных очень много, а расчёты нужны моментальные. То есть задержка даже не секунды, а миллисекунды. Кэша твоего лэптопа не хватит, поэтому ты распределяешь данные по оперативке десятков или сотен машин.
Конечно это не всем нужно. Если ты делаешь магазин для ИП Ашот и Ко, то это на хуй не надо. Можно все сделать на пэхэпэ и постгрес
Слушай, ты хоть кабанчика почитай, что ли. Ты же вообще нихуя не понимаешь, как работает сеть, как хранятся данные, несешь хуету про машин лернинг для сраного кэша, вообще охуеть.
Погоди, если я правильно понял, ты симулируешь in-memory базу с шардингом?
>Мешает. Данных очень много, а расчёты нужны моментальные.
Бля, больше десяти лет уже прошло, а джаваскрипт макаки все еще на серьезном ебале думают что мапредьюс это супир быстро и всем дает посасать.
>Данных очень много, а расчёты нужны моментальные
Рекомендательные системы обычно лопатят кучу данных и подготавливают ответ оффлайн.
Просто делай 30 рекомендаций и фильтруй онлайн по наличию товаров.
Выгода в том, что ты можешь намного более сложные штуки подключить чем ты смог бы закодировать в SQL
>Я так же видел зоопарк sql + nosql на одностраничном складе фотографий.
ты про gallery2 ?
http://codex.galleryproject.org/Gallery3:Features.html
Ну он рулил, хотя и представлял из себя ORM-шизу.
Но сейчас-то ВЕЗДЕ так.
В ОРМ нет никакой шизы. Это просто ДРУГАЯ задача. Генерация простых запросов за тебя. Кайф же.
Даже когда ни ты ни твоя ОРМ не можете написать рекурсивный запрос и тупо выкачиваете все данные на бек - это не шиза, это просто криворукость и лень.
А вот когда криворукость и лень преподносятся как ПРАВИЛЬНЫЙ способ - вот это шиза.
То же самое и с технологиями. Если эта замечательная технология делает лучше/быстрее просто вот так. То офк надо брать. Только вот законы физики не наебешь, и в 99% случаев в комплекте идут ебейшие недостатки. Типа закупки нескольких терабайт ecc оперативы для твоего охуенного "RAM кластера", который мапредьюс делает.
Я вот лично ничего против монги не имею, но каждый раз как прибегает монгохуесос и заявляет что монга что-то делает лучше. Он не может с её помощью решить ни одной прикладной задачи. Бегает по треду, орет и постит смешные картинки. При том то на SQL все это делается любым интерном за пять минут.
>В ОРМ нет никакой шизы. Это просто ДРУГАЯ задача.
Я знаю. Просто нам это не нравится.
Она усложняет работу всех тех, у кого БД в фокусе.
>с её помощью решить ни одной прикладной задачи
А была хоть одна ПРИКЛАДНАЯ задача?
Написать иннер за 5 минут — это манязадача с собеса.
Плохо когда ты постгресошизохуесос и нихуя в технологиях не разбираешься, да?
Это не мапредьюс, а кейвелью, поэтому да, это супир быстро и всем дает посасать.
Никак.
Во первых: это вообще незаконно. 426 ГК РФ. Но это права потребителей, кого в этой стране вообще права гречневых ебут.
А вот во вторых: если тебя и не нахлобучат по 426, то тебе по этим ценам бух отчетность писать и НДС платить. Разная цена = разный НДС. На один и тот же товар с одной и той же закупочной. А это уже уклонение от налогов со всеми вытекающими.
Вот тут-то тебя выебут без смазки, и крыша никакая не поможет.
>Во первых: это вообще незаконно.
В перекрёсток зайди в центре Москвы и где-нибудь на окраине в Твери — цены разные. И даже в одном магазине цена для некоторых товаров разная для анонимного покупателя и идентифицированого, который карту лояльности прокатывает.
Тоже самое с маркетплейсами. Много раз было когда у меня цена одна, а у друга-брата-свата в этот же момент времени, но в другом регионе немножко другая. Если у тебя подписка есть, цена третья. А если Яндекс Pay каким-нибудь оплатишь вообще другая цена.
ГК не нарушается, не переживай. Так как цена реально будет одна и та же абсолютно для всех. Это просто акция для жителей конкретного региона. Или персональные скидки для всех анонов, кроме тебя.
>то тебе по этим ценам бух отчетность писать и НДС платить
Это не проблема в век информационных технологий. Ставишь задачу айтишникам и они делают любым интерном за пять минут.
>Или персональные скидки для всех анонов, кроме тебя.
Сказочный долбоеб. Будешь в налоговой объяснять почему у тебя с партии товара недоплата НДС идет. Хотя... до этого никогда не дойдет, потому что еще на этапе идеи главбух тебе леща въебет, сидеть-то ей а не тебе, лол.
Ты бы знал какая ебля оформлять бонусную программу по документам. Там год юридической подготовки минимум уйдет. А всякие "платиновые" статусы на самом деле по документам нихуя не статусы, а какие-нибудь "услуги".
Чел ты похоже тупой даун который живёт в каком-то манямирке и с реальным миром не взаимодействуют
Я тебе реальный примеры привёл.
В Перекрёсток зайди. Там на ценнике две цены.
Одна для всех, другая только для тех у кого есть карта лояльности.
НДС тебе сложно платить? А кого это ебёт?
Мудила гороховый, ценник это публичная оферта. А бонусная карта это следствие оформления ДОГОВОРА.
Цена на ценнике только одна, это должно быть самое крупное число. Это публичная оферта, по этой цене тебе обязаны продать товар по закону. Второе/третье/перечеркнутое число это не цена, а просто рекламная цифра, никакого юридического смысла она не несет.
А вот снижение основной цены и сумма за которую тебе на самом деле продадут товар определяется заключенным тобой ранее договором, при подписании которого тебе и выдали "скидочную карту", статус которой тоже должен быть прописан в договоре.
>ценник это публичная оферта
>Второе/третье/перечеркнутое число это не цена, а просто рекламная цифра, никакого юридического смысла она не несет.
А кто-то спорит разве? Всё именно так. И я так написал. Ты жопой что ли читал?
Вот смотри один и тот же товар в двух разных регионах.
Ценник в 1279₽ , он же публичная оферта, одинаковые для всех.
Никакого ущемление прав какой-либо группы лиц нет. Все согласно закону.
А далее просто рекламные цифры, которые юридического смысла не несут, но тем не менее именно по этим рекламным цифрам покупатель приобретёт товар.
И я говорю как раз вот про динамическое ценообразование этих рекламных циферок.
>Ты бы знал какая ебля оформлять бонусную программу по документам. Там год юридической подготовки минимум уйдет.
Ты даун поэтому у тебя год уйдёт. Берём любую продуктовый сеть, где каждый божий день есть скидка на некоторые товары для всех, на другие товары для владельцев карт лояльности, скидки на промо товары, скидки на товары с почти истекшим сроком годности, скидки за баллы, за большую сумму покупки, за минет твоей мамки. И все это меняется ежедневно, а не раз в несколько лет, пока ты тормознутый даун будешь юридическую подготовку делать.
>Берём любую продуктовый сеть, где каждый божий день есть скидка
И эти скидки вместе с оформлением ООО в комплекте идут?
Я когда в не самом крупном ритейлере работал, там только 1С макак было тридцать штук. Это только тех кто инструменты для бухгалтерии писал. Самих бухгалтеров я вообще хуй знает сколько было - отдельный офис трехэтажный.
Там был АРХИВ нахуй с архивариусом, потому что квартальная отчетность это пятьдесят КОРОБОК с мукулатурой, ебучий трехметровый стеллаж. И храниться все это говно несколько лет должно, чтобы если че можно было за любой косяк нахлобучить.
Меняется у него блядь ежедневно. Само ебать меняется. Ну ты и выдал, долбоеб.
>по этим рекламным цифрам покупатель приобретёт товар
Если заключал договор. ДОГОВОР, слепой ты долбоеб. И именно в этом договоре четко должно быть описано по каким правилам будет меняться цена.
Нельзя блядь в договоре написать: ну кароч наша нейросеть будет на рандоме ценник хуярить, окда? Там указываются конкретные числа: при покупке на сумму от... каждый потраченный рубль соответствует скидке в сумме... и все это должно быть отражено в отчетности, буквально с указанием дат предыдущих покупок, на основе которых сформирована скидка. С отдельной еблей в очко если происходит переход на следующий год.
А самое главное что это все только при СНИЖЕНИИ цены. Не дай аллах тебе цену хоть на рубль повысить. За такие фокусы сразу пизда. То есть речь идет не о "расчете цен", а только о "формировании скидки".
А при расчете исходной цены нельзя, например, использовать данные конкурентов. За такое тебя нахлобучит уже ФАС. И им похуй будет нейросеть там тебе цену формировала или мясной долбоеб. Можешь загуглить "картельный сговор роботов". Несколько лет назад крупных ритейлеров ебнУли и поимели с них немножко денежек за такую хуйню. И на все отмазки типа "ой ну знаете это жи все кампудахтер вычисляет, автоматически" было строго похуй.
Как можно быть таким тупым?
Этот тред про IT. А конкретно про базы данных и про данные в них.
И как один из примеров как можно использовать эти данные для динамического ценообразования.
Какой на хуй договор? Какой на хуй ГК? Ты ёбнулся что ли?
Ну я бы тебе конкретный пример привёл на Яндекс маркете, что разные покупатели видят разную цену на один и тот же товар и соответственно купят его по разным ценам.
Хули ты тут тред засираешь?
Иди засуди Яндекс маркет перекрёсток ozon и прочие крупные ретейлы.
Потом засудили авиакомпании отели такси. РЖД конечно не забудь.
Ты что даун что ли запугиваешь двачеров фасом, лол!
Или хватит пиздеть и просто иди на хуй.
>Никак.
>Во первых: это вообще незаконно.
>>3148157
Перестань срать в доску про фасы договоры и прочую хуету. Всем уже и так ясно что ты обосрался в вопросе в котором нихуя не разбираешься
>А при расчете исходной цены нельзя, например, использовать данные конкурентов. За такое тебя нахлобучит уже ФАС.
ЛОЛ! Мальчик похоже насмотрелся голливудских фильмов про IT. Практически во всех компаниях что я работал есть целая команда которая занимается парсингом сайтов конкурентов и всех прочих что может принести пользу. И скажу даже по секрету, все с удовольствием качали слитые базы Яндекс доставки и прочих чтобы использовать для анализа и обучения своих моделей.
>Можешь загуглить "картельный сговор роботов". Несколько лет назад крупных ритейлеров ебнУли и поимели с них немножко денежек за такую хуйню.
Один случай из 1000. Чё там ФАС сделает?
>Доказать сговор удалось благодаря анализу настроек аукционных роботов – у обеих компаний они были практически идентичны. Роботы делали все, чтобы завершить торги в первую же секунду со снижением цены в 0,5% от максимальной (начальной). Обеим оптовым компаниям грозили штрафы по 35 тысяч на руководителей организаций и порядка 330 тысяч рублей на каждое юрлицо.
Ахаха, как страшно. Да и похуй. Велью от инсайтов полученных из этих данных гораздо больше на несколько порядков.
>Hoff
>наши категорийные менеджеры предпочли верифицировать вручную, так как экспертная оценка в этом случае была крайне важна
Там вообще МЛ используется для "поиска аналогов", и то бля все в ручную потом обрабатывается. Никаких цен Мл не формирует. Тем более индивидуальных.
>Азбука вкуса
>Система разработана международной компанией GoalProfit
>Sorry, this page doesn't exist.
Сайт системы редиректит на 404. Наверное что-то случилось. ГООООООЛ.
Опять же, даже если сайт лежит "временно/случайно" речи об индивидуальных ценах нет. Как и следов использования МЛ.
>Хуяндекс.Хачси
>Мы решили позаимствовать у машинного обучения метод ближайших соседей для задачи регрессии
Это литературно единственное применение МЛ в их ценообразовании. Буквально "рядом лежало". Это блядь уже комедия какая-то - эти долбоебы написали P.S что настоящее МЛ у них используется... в другом месте, хули ноете.
Последняя статья вообще про муррику. И опять непонятно причем там вообще МЛ. Ну придумали хитрожопые барыги менять цену в зависимости от расстояния мобилы до магаза, ну написали скрипт. Нахуй тут "лернинг" уебался. Разве что обучение клиентов отключать отслеживание в мобиле.
Короче ты сам себе в штаны насрал. Никто не использует МЛ для формирования цен. И уж подавно никто не использует МЛ для формирования индивидуальных цен. Динамическое ценообразование офк есть, этого никто и не отрицал, только это процесс сложный и ограниченный определенными правилами, МЛ в нем нахуй не нужен. Вот сопоставить товары по фото это пожалуйста, маршрут "угадать" вместо честного просчета тоже да. А цены слишком точная и важная хуйня, чтобы её генератору шума доверять.
Вообще по откровенном попыткам нагнать хайп в этих статьях можно сделать довольно точный вывод о том кто этот кал потребляет. ГОВНОЕД, нахуя ты эту поебень читаешь? Там пидарасы уже даже не стесняются - тупо лепят тег "машинное обучение", а ты жрешь эту хуйню, еще и сюда тащишь. Фу блядь, фу нахуй.
Ты какую-то хуйню загуглил. Какие нахуй аукционы, ебанько?
Вот о чем речь была
https://www.vedomosti.ru/business/articles/2017/09/07/732731-robotov-sgovore
>Управление Федеральной антимонопольной службы (ФАС) по борьбе с картелями в середине августа провело встречу с вендорами и ритейлерами электроники. Цель – обсудить программы для мониторинга и сравнения цен в интернете, так называемый парсинг.
>служба установила, что некоторые торговцы и поставщики используют роботов, чтобы определять цены товара на полке или контролировать розничные цен на продукцию конкретного бренда
И этим "конкретным брендом" был Альберт Эйнштейн LG
>Участники рынка с опасениями ФАС не согласны.
Еще бы они блядь были согласны. Но, спойлер, их согласие никого не ебало. Им въебали несколько лямов штрафа каждому.
И у нас руководство всех программистов собрало и стало решать как бы так наебать, чтобы продолжать парсить. Думали гадали, в итоге только один вариант рабочий - парсить должна сторонняя компания, а ритейлеры у неё будут покупать "просто цены", хуй знает чьи. Офк смысл от такого парсинга сильно теряется. Но когда любой стукачек может выставить контору на несколько лямов штрафа, приходится хавать.
>Чё там ФАС сделает?
А будешь выебываться - изымут сервера на "проверку". Ботов искать зловредных. Ты думаешь нахуя закон о возвращении данных в родную говень был принят?
С налоговой веселее. Пишут что недоплачено налогов на лям из трехсот, и похуй что вы и три ляма готовы прям щас отдать, только чтобы отъебались. В офис прибывает НОМО и усердно ищет пропавший лям.
>Во первых: это вообще незаконно. 426 ГК РФ
>Динамическое ценообразование офк есть, этого никто и не отрицал
>Внимание! Я не обосрался! Повторяю! Не обосрался
> Никаких цен Мл не формирует
> сайт не открывается
> Это блядь уже комедия какая-то
> статья вообще про муррику
ЛОЛ! Что за манявры пошли?
Мы разве обсуждали как у кого-то и на чем цены формируются?
Похуй что они там используют. Хоть МЛ, хоть сприпты на фортране.
Вопрос был про динамическое образование цен.
Что одному пользователю показывает одну цену, а другому пользователю показывает другую цену.
Что днём цена одна, ночью другая. Что на iPhone одна цена а на андроиде другая.
На что ты ответил, что не существует и не законно, а потом неожиданно переобулся.
>>3148265
>>служба установила,
Ну я установил что ты пиздабол который обдристался на дваче при всех и что дальше?
>Им въебали несколько лямов штрафа каждому.
А чего не триллиардов? Пизди побольше для важности
>Думали гадали, в итоге только один вариант рабочий
Ты при этом тоже всем рассказывал про договоры оферты и запугивал фас?
Или ты только такое пиздишь, пытаясь показать что тут самый важный?
>А будешь выебываться - изымут сервера на "проверку".
>С налоговой веселее.
>В офис прибывает НОМО
В какой офис? Десятки даже сотни офисов по всей России?
Как ты вообще представляешь чтобы в ВТБ или МТС или перекрёсток прибыла налоговая с омоном и начали все изывать?
Какие серваки? Там целые датацентры.
Вот прям весь датацентр увезут и допустим порушат все сотовую связь в регионе?
Или ты про малый средний бизнес?
Ну так вас всё равно будут кошмарить.
Неважно есть у вас динамические цены или нет.
Есть у нас картельные сговоры или нет.
>Что одному пользователю показывает одну цену, а другому пользователю показывает другую цену.
>
чел ты даун кукаретик
мимо
Это как дауны, которые не нашли /s/ и срут здесь. Нет бы съебаться в /law/.
>Посоветуйте курсы хорошие. Биг дата, разработчик БД или дата архитектор. Бюджет на обучение выделен, на то что я хотел пойти либо ушли из России либо закрылись.
Аноны, по курсам подскажите?
Если упростить, у меня есть две таблицы: в первой числовое значение и внешний ключ на вторую таблицу, во второй также числовое значение. Я хочу чтобы при каждом добавлении записи в первую таблицу, он изменял запись второй таблицы на которую ссылается созданная запись, так что к числовому значению записи из второй таблицы будет прибавляться числовое значение из созданной записи в первой таблице.
CREATE TRIGGER sum_tables AFTER INSERT ON table_1
FOR EACH ROW
BEGIN
UPDATE table_2
SET value2 = value2 + new.value1
WHERE id = table_2_id;
END;
Выдает ошибку и т.к. я до конца не понимаю как правильно обращаться к значениям в других таблицах, думаю проблема именно в
WHERE. Но как правильно написать все равно не понимаю пока, так что прошу помощи...
Запрос где? Ошибка где?
https://dbfiddle.uk/
Да конкретной ошибки то и нет, просто не до конца понимаю как правильно триггеры писать.
https://dbfiddle.uk/ZT2Xar-a
>Да конкретной ошибки то и нет
А вот эта красная хуйня чисто по приколу висит? Написано же: BEGIN в триггере нельзя использовать. Откуда ты его взял вообще?
https://www.postgresql.org/docs/current/sql-createtrigger.html
>The trigger will be associated with the specified table, view, or foreign table and will execute the specified function function_name when certain operations are performed on that table.
Триггер функцию вызывает, а уже в функции ты делаешь то что тебе нужно https://https://dbfiddle.uk/V0NLwhYD
1) Называй таблицы ключи и процедуры так, чтобы по названию можно было понять что куда и откуда.
2) Если указываешь тип SERIAL, то и работай с ним как с SERIAL.
3) Триггеры в целом так себе идея. Гораздо лучше будет если ты выполнишь сам в транзакции два запроса - на инсерт и на апдейт.
Бля, забыл ссылку на доку
https://www.postgresql.org/docs/current/plpgsql-trigger.html
Эта хуйня так и называется: Триггерные процедуры.
>Никто не использует МЛ для формирования цен.
Крупные ретейлы, маткетплейсы, и даже обсосы используют.
Я работал в нескольких крупных компаниях, в которых каждый россиянин хотя бы раз в жизни что-то купил. Конкретно я это не делал, мои задачи были перекладывать данные из одного места в другое, но ребята пилили модели. Практически в любом месте где есть много точек и массовые продажи нужно решить три задачи: по чём продавать, сколько остатков держать на складе, сколько сотрудников выводить на точку. Если у тебя есть история продаж за десятки лет, то на все эти вопросы отлично отвечают ИИ.
>то на все эти вопросы отлично отвечают ИИ
Бля, и что же ИИ отвечают на эти вопросы?
Отвечают: ебанько, у тебя есть закупочная, себестоимость и ррц, ты че генерировать собрался?
Охуеваю с долбоебов с магическим мышлением.
Присылай резюме. У нас как раз ML инженера ищут еще одного. Зарплата для сеньора от 400к + годовая премия 20% от годовых доходов.
Я за это бонус получу, а ты узнаешь как ML работает — оба в плюсе.
>Зарплата для сеньора от 400к + годовая премия 20% от годовых доходов
Баляяя, эти фантазии потребителя курсов. А еще полцарства и дочь CEO в жены.
Сорян братишка, но твоя выдуманная конторка мне не по размеру.
Я занимаюсь реальным машин лернингом - делаю таргетированную рекламу для яндекса. Если тебя неделями после одного единственного поиска заебывала реклама хуйни, котрую ты давно купил, то знай - это я. Мы предиктивно-адаптивно машин лерним нейросети ИИ, чтобы улучшить опыт наших клиентов, получая премию 50% с налерненых за год доходов.
>Если тебя неделями после одного единственного поиска заебывала реклама хуйни, котрую ты давно купил, то знай - это я.
Ты гордишься тем, что сливаешь деньги рекламодателей в пизду? Похвально. Одобряю. Так держать! Но лучше форсировать.
>сливаешь деньги рекламодателей в пизду
Ты че, пес. Нейросеть не ошибается. Надежная вещь, вы определенно можете ей доверить свои деньги но лучше чужие.
Мы, машин лернеры, не обманываем друг друга.
>форсировать
Теперь это тред дружной форсированной нейросемьи.
> делаю таргетированную рекламу
О прикинь я тоже. Только в другой компании.
Динамическими ценами соседняя команда занимается
>Я занимаюсь реальным машин лернингом
Да по сути одно и то говно. Зазывала продажник, просто не табличку крутишь у магазина, а модели в тензорфлоу
В компании есть 3 сегмента клиентов (сегмент_1, сегмент_2, сегмент_3), при этом клиенты бывают действующими и бывшими, клиенты также имеют разное количество подключенных услуг и находятся в разных городах.
Вся информация о клиентах хранится в таблице clients. Структура таблицы выглядит так: (приложил картинкой)
Необходимо выполнить следующие запросы:
Запрос №1.
Необходимо выбрать всех действующих клиентов сегмента_1 с количеством продуктов больше 2 и находящихся в регионах 002 или 003 или 007.
Запрос №2.
Необходимо написать запрос, позволяющий понять распределение кол-ва клиентов в разрезе сегментов, признака flag_client и региона. Используйте агрегирующие функции
Запрос №3.
В предыдущий запрос необходимо добавить значение по среднему количеству услуг на одного клиента. Если у клиента нет услуг (cnt_services = 0), тогда необходимо подставить среднее значение по данному региону и сегменту
₽5к и я напишу тебе все запросы и объясню как работает если нужно
тг: suqily
>Необходимо выбрать всех действующих клиентов сегмента_1 с количеством продуктов больше 2 и находящихся в регионах 002 или 003 или 007.
Что-то типа
select inn from clients
where flag_client = 1 and id_city in (001, 002, 007) and cnt_services > 2
ты ахуел?
а зачем тогда вообще в elasticsearch созданы эти методы и индексы?
>. Всего около 300к документов в одном шарде
И это все, чем ты смог описать свою систему?
Один ебанат ничего сформулировать не может, другой ебанат ему советы раздает..
давай убедимся, что ты прочитал и опробовал тут все https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-knn-search.html
И что у тебя есть мониторинг чтобы понять какой из ресурсов активно использует в моменты нагрузки на поиск
По большей части там советы "а может поменьше сделаешь вектора?) Оптимизируй, чтобы не было индексации и серча одновременно". В общем проблему я в итоге решил обычной квантизацией, которую можно прям в индексе задать. Пока что не заметил проблем с результатами. Буду дальше тестить. Спасибо за наводки!
>elasticsearch
>Всего около 300к документов
Забей. Эластик на жабе написан и тормозит уже на паре тысяч документов где латенси 99% плавает в 500-700 мс. Просто провальный проект как и кафка. Ищи альтернативы на нормальных языках программирования
>Ищи альтернативы на нормальных языках программирования
так их нет.
есть какое-то дрочение, типа расширение для postgres, но мутное и малопопулярное.
может что-то конкретное предложишь?
Да это какой-то шиз. Забей на него.
Я сам не фанат джавы, но только дурак будет отрицать ее производительность и масштабируемость, что важно для систем обработки больших данных. Поэтому и Elasticsearch и Kafka и Hadoop и Cassandra и десятки других инструментов для обработки больших данных написаны на Java
>Elasticsearch
Meilisearch
>Kafka
Redpanda
>Hadoop
Clickhouse
>Cassandra
Scylladb