Ссылки:
- 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.
