Это копия, сохраненная 3 июля 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Туториалы на русском для тех, кто не умеет гуглить, не может в английский и вообще готов жрать что угодно:
SQL:
- MySQL, Postgres, SQL Server: https://metanit.com/sql/
- Синтаксис SQL кратко: https://learnxinyminutes.com/docs/ru-ru/sql-ru/
- Плейлисты по разным СУБД: https://www.youtube.com/c/SQLDeveloperBI/playlists
- Тоже плейлист, сортировка хуёвая: https://www.youtube.com/watch?v=EHvzvwAv7RU&list=PLY7PmJJFH5nT-lbFKxfbp3rw5BBuq5Azo[РАСКРЫТЬ][РАСКРЫТЬ][РАСКРЫТЬ]
- https://www.youtube.com/c/SQLDeveloperBI
NoSQL:
- MongoDB: https://metanit.com/nosql/mongodb/
- Cassandra: https://proselyte.net/tutorials/cassandra/
На инглише:
SQL:
- https://www.w3schools.com/sql/
Литература:
- Прибыл Фейерштейн. Oracle PL/SQL. Для профессионалов - если уметь исказть, можно найти бесплатно без СМС и на русском.
- Алан Бьюли. Изучаем SQL. - про MySQL, тоже легко находится. Довольно старая, но базовые вещи не сильно меняются.
- К. Дж. Дейт. Введение в системы баз данных - талмуд на овер 1000 страниц.
- Томас Кайт. Oracle для профессионалов - тоже талмуд.
Задачки для оттачивания sql-скилов:
- https://www.sql-ex.ru
- http://sql-tutorial.ru/
- https://www.codewars.com/?language=sql
ETL, OLAP, DWH и другие умные слова:
- https://www.youtube.com/watch?v=WPZuzDJXs-Q&list=PLhhjwMYxzolhP29LSPPwORVQxJX5OjYix[РАСКРЫТЬ][РАСКРЫТЬ][РАСКРЫТЬ]
- OLAP DAX Power BI: https://www.youtube.com/playlist?list=PLhhjwMYxzolhXuySjLR2_n-xb6VvWnjju
Прочее:
- 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/
FAQ:
Q: Нужно ли знать английский?
A: Да.
Q: Что лучше, SQL или NoSQL?
A: Как обычно, зависит от задач. Нужна любой ценой скорость - бери NoSQL, нужна согласованность данных - SQL. У всего свои плюсы и минусы, и в обозримом будущем ни один подход не заменит другой полностью.
Q: Вопросы с лабами и задачками
A: Смело спрашивай, с вероятностью больше 50% ответят, но могут и обоссать.
Здесь мы:
- Негодуем, почему шапка - говно, и предлагаем коллективному ОПу идеи, как её улучшить.
- Разбираемся, почему PostgreSQL - не Oracle
- Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
- Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обеществе
- Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
- Анализируем, как работает поиск вконтакте
- И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно
MERN
Большинство так и не умеет, а если надо, за полчаса гуглят синтаксис PL/SQL и аналоги функций из ЯПов, которые знают.
Нинужно.
На работе учил, будучи джуном нулевым. Специальную литературу не читал. И ничего, свои три сотыги имею!
Да!
Оконные функции мб.
Давно не юзал SQL. Гуглю уже 3-й час всякую хуйню и что-то никак не могу вкурить, как работают primary и foreign ключи. Понял, что устанавливаются зависимости. Но не понял как я могу это использовать при выборке данных или я вообще их юзать даже не должен?
Выкупаю, что надо использовать SUM и COUNT по каждой стране производителя, но как правильно условие написать не вдупляю.
Помогите, пожалуйста, если есть свободное время
>как работают primary и foreign ключи. Понял, что устанавливаются зависимости. Но не понял как я могу это использовать при выборке данных или я вообще их юзать даже не должен?
У тебя одна табличка ставится в соответствие другой как раз по CompanyId. То есть в табличку phone досасывается инфа о компании (страна, название страны).
Хз чето вроде пикрила, хуй знает
а ну канеш забыл КАУНТ(телебонстер.модель) в СЕЛЕКТ вписать
UPD:
Сообразил до такого
SELECT c.companyName, COUNT(p.phoneModel) as COUNT, SUM(p.price) as SUM FROM phone as p, company as c
WHERE p.companyId=c.companyId GROUP BY p.companyId;
Выдает то, что на пике. Но по условию должны отображаться все компании, даже без мобил. Как сделать, чтобы отобразилась она?
Спасибо, друг. Я твой пост не увидел, рабочий интернет залагал.
Твой способ поможет отображать все компании?
>Твой способ поможет отображать все компании?
Должно работать (наверное), лефт жоин же, т.е. должен показывать даже если телефонов в phone 0 штук от этого производителя
Чет не получается. Ошибку синтаксиса выдает. Видел сверху мою строчку? Куда там надо left join хуйнуть?
Всё, чувак. Получилось без лефт джоина. Я, наверное, инвалид, но не вдуплил как таблицы так скрестить, поэтому другим путем пошел.
SELECT companyName, (SELECT COUNT(phone.phoneModel) FROM phone
WHERE phone.companyId=company.companyId) AS COUNT, (SELECT SUM(phone.price) FROM phone
WHERE phone.companyId=company.companyId) AS SUM
FROM company GROUP BY company.companyId;
Прикольная задача!
Красиво не решилась на 6 году карьеры узнал, что в оконной функции нельзя делать count distinct
Поэтому вот так через жопку, буду рад, если кто-то придумает вариант красивее.
Решение такое: для каждой строчки делаю подзапрос на три последних покупки клиента, включая текущую. В подзапросе условие на то, что там различных продуктов 1 (то есть клиент купил три раза подряд одно и то же), и дополнительное условие на обычный count для обработки граничных условий (иначе бы условие на count distinct срабатывало бы и для первой покупки клиента, что неправильно).
Круто? Круто.
Результат обрезал нечаянно. В общем, этот запрос вернет клиента номер 1, потому что для него выполнены условия в инсертах с 3 по 5 (три раза подряд купил продукт сталин 3000)
Пацаны, у меня по этой схеме снова затык. Только задачка иная. Нужно найти самые дорогие модели телефонов у каждого производителя.
Я понял как вывести наименование производителя и цену, но подвязать модель не получается.
Когда подвязываю модель, он начинает искать MAX(price) по каждой модели.
Есть таблица с событиями, нужно выбрать последнее событие каждого типа.
Вижу два стула:
1) Через ров намбер, потом фильтровать из with
2) Через группировку в where, чтобы получить тип события.
Но мне оба варинта кажутся медленным говном, первый потому-что надо делать выборку всех данных, второй потому-что если типов обьёктоа объектов много, можно упереться в лимит where.
Есть ли ещё стулья?
Эта задача в любом случае подразумевает выборку всех данных.
Первый вариант норм, второй вариант шизоидный, вообще не понял о чём ты.
груп бай продаван
first_value(событие) over(partition by тип order by дата desc)
Остановился на этом:
SELECT Shop, Item, SUM(Orders) AS Orders FROM table
GROUP BY Shop, Item
ORDER BY Orders DESC
Запрос вернёт отсортированную сумму заказов конкретного товара для каждого магазина. Как теперь выбрать только наиболее продаваемый товар и общую сумму заказов?
Спасибо, очень помог
Mysql Же
У тебя проблема не в mysql, а в синтаксисе php.
https://docs.oracle.com/database/121/ARPLS/u_match.htm#ARPLS352
https://www.postgresql.org/docs/current/pgtrgm.html
Для этого какой-нибудь elasticsearch лучше подойдёт.
Як стать тру датабейс девелопером, что считается тру? Как быть тру? Што нужно чтоб мне платили хотя бы 100к.
Залетать на стажировки, если у тебя есть приличная вышка и тебе меньше 25 лет.
В остальных случаях, вероятно, никак. К счастью, моя профессия не расхайпана инфоцыганами, поэтому ты вряд ли найдешь курсы "Как стать разработчиком БД с нуля".
Я этим уже занимаюсь скажем так, но я использую sql лишь для бека, мне грят што надо мне будет полноценно вкатываться сюдыть, вот я спрашиваю где как не на двачах срашивать что нужно знать датабазе мастеру.
>моя профессия не расхайпана инфоцыганами, поэтому ты вряд ли найдешь курсы "Как стать разработчиком БД с нуля"
У авторов teachyouselfcs есть мысль что все кто мог норм книги по дб написать и курсы преподать свалили работать. Ждём пока на пенсию выйдут.
Есть сущность аккаунт с балансом. И есть переводы. Как запретить переводы если сумма перевода больше баланса отправителя?
Ограничение на баланс поставить, типа неотрицательный? Хранимку какую то? Как это сделать внутри базы?
Пока только вариант внутри кода перед транзакцией вызывать селект и там проверять. Но мне как-то не очень это нравится.
Спасибо.
Самый нормальный вариант, все остальное это неявная пидорская логика.
А ещё можешь перед операцией блокировать строчку с аккаунтом, чтобы не получилось так, что ты пропустил в один момент времени две транзакции, которые в сумме дали больше, чем баланс счёта.
Ну вот и я подумал, что проблема не в лишнем селекте, а что операция с селектом вне транзакции неатомарна.
А что за блокировки? Целой таблички или отдельной строки? Я просто про очень короткую книжечку читал и вообще по майсикулю, там такого не было.
https://habr.com/ru/company/postgrespro/blog/463819/
Ты вот об этом?
Построчно, конечно, иначе у тебя никакой параллельности не будет.
>Ты вот об этом?
Да. Но конкректно про постгрес я тебе не расскажу, статью почитай.
Спасибо
Укажи ON DELETE CASCADE при создании внешнего ключа.
>Пока только вариант внутри кода перед транзакцией вызывать селект и там проверять.
Это и есть самое оптимальное решение
>Но мне как-то не очень это нравится.
Почему? А что тебе нравится? Чтоб база ещё больше бизнес-логики начала в себе хранить, помимо самих реляций?
>операция неатомарна
Ну у тебя в любом случае будет отдельно селект, проверяющий легитимность транзакции, и отдельно инсёрт.
Не знаю. Я же не шарю. Ну вот я думал можно ограничение на неотрицательность поставить и если в ограничение попадешь, то там откат какой нибудь или типа того.
Откат это тяжелая операция для БД, поэтому лучше до него не доводить. Говорю как специалист в БД Оракл, не уверен, что у вас так же, но все-таки это даже с позиции здравого смысла нелогично делать операции, которые будешь откатывать.
Поясни ньюфагу про бизнес-логику в базе. Зачем вообще нужны эти сложные запросы с оконными функциями и подзапросами, если это можно делать в самом коде получая все записи? И почему язык запросов не является императивным, как нормальные яп? ибо эта хуйня нихуя не интуитивна
> Зачем вообще нужны эти сложные запросы с оконными функциями и подзапросами, если это можно делать в самом коде получая все записи?
Представь, сколько оверхеда будет из-за пересылки данных через сокет от БД к основному приложению и последующего преобразования этих данных в объекты, понятные основному ЯПу.
> И почему язык запросов не является императивным, как нормальные яп?
Ты описываешь результат, который хочешь получить, вместо алгоритма для его получения, и оптимальный алгоритм подбирает СУБД, которая справляется с этим намного лучше, чем написал бы среднестатистический кодер. Попробуй посмотреть на план запроса для сложного случая, заебёшься такое писать сам.
мимо
А орм-ки используют функции баз?
>Поясни ньюфагу про бизнес-логику в базе. Зачем вообще нужны эти
То что ты дальше спрашиваешь это не бизнес-логика в базе, это технические детали СУБД. Бизнес-логика это знания из предметной области, которые отношения к БД и тем более СУБД не имеют, как раз как твой пример с "если эта операция загонит баланс в минус, то её нельзя выполнять". С точки зрения базы и её управления эта инфа нерелевантна — базе похуй что хранить, поэтому такую инфу хорошим тоном является отделять от пердолинга с базой, как тебе и посоветовали. С другой стороны база один хуй всегда хранит часть бизнес-логики — это описание реляций, т.е. метаданные базы, т.е. вот это вот "у меня есть таблица товар и таблица склад, в таблице склад есть две колонки — ссылка на таблицу товар и количество товара на складе". Строго говоря, вся эта инфа это часть бизнес-логики, она отражает предметную область, но без неё базе непонятно что и как хранить, поэтому она хранится в базе. Но мы стремимся хранить в базе данных только ту часть бизнес-логики, которая там совершенно необходима, чем меньше тем лучше.
>Зачем вообще нужны эти сложные запросы с оконными функциями и подзапросами, если это можно делать в самом коде получая все записи? И почему язык запросов не является императивным, как нормальные яп?
Выше ответили — чтобы дать возможность СУБД самой выбирать оптимальный алгоритм чтобы получить то, что ты там насочинял.
>ибо эта хуйня нихуя не интуитивна
Согласен, но к этой хуйне привыкаешь и она того стоит.
>>139124
По той же причине — чтобы плотили деньги, но только в этот раз не за знание пердольного декларативного языка, а за знание очередных НОВЫХ ФРЕЙМВОРКОВ, которые выходят по одному в месяц.
Всё программирование в капиталистическом мире (я сейчас не осуждаю и не восхваляю капиталистический мир, а просто констатирую печальный факт) неизбежно вырождается в сложность ради сложности, потому что за сложность платят, а за простоту — нет. На эту тему неплохо высказался покойный любитель асма и эффективности https://www.km.ru/referats/778A5D749ACE4041AC2D3D803C05DBBC
>Самолеты и космические корабли мирно сосуществуют с велосипедами и автомобилями. Никому ведь и в голову не придет летать за сигаретами на ракете, особенно если сигареты продаются в киоске на соседнем углу.
>Но ведь это же неправильно! Появление ракет должно перевернуть наше мышление! Поэтому—строим киоск за орбитой Плутона и каждому даем по ракете, чтобы туда летать, а горючее покупаем за деньги, вырученные от строительства космодромов и продаж ракет. Кто не может строить ракеты — пусть учит других, как на них летать. Сколько создается новых рабочих мест и главное, что все в бизнесе. Вот тут уж действительно, возврата в прошлое нет... Сигареты стоят миллиарды долларов, и деньги в индустрию вращаются просто огромные. Кто же захочет от них отказываться?! Напротив, ракеты будут стремительно «совершенствоваться», чтобы за сигаретами можно было летать даже на Альфу Центавра.
>Поясни ньюфагу про бизнес-логику в базе. Зачем вообще нужны эти
То что ты дальше спрашиваешь это не бизнес-логика в базе, это технические детали СУБД. Бизнес-логика это знания из предметной области, которые отношения к БД и тем более СУБД не имеют, как раз как твой пример с "если эта операция загонит баланс в минус, то её нельзя выполнять". С точки зрения базы и её управления эта инфа нерелевантна — базе похуй что хранить, поэтому такую инфу хорошим тоном является отделять от пердолинга с базой, как тебе и посоветовали. С другой стороны база один хуй всегда хранит часть бизнес-логики — это описание реляций, т.е. метаданные базы, т.е. вот это вот "у меня есть таблица товар и таблица склад, в таблице склад есть две колонки — ссылка на таблицу товар и количество товара на складе". Строго говоря, вся эта инфа это часть бизнес-логики, она отражает предметную область, но без неё базе непонятно что и как хранить, поэтому она хранится в базе. Но мы стремимся хранить в базе данных только ту часть бизнес-логики, которая там совершенно необходима, чем меньше тем лучше.
>Зачем вообще нужны эти сложные запросы с оконными функциями и подзапросами, если это можно делать в самом коде получая все записи? И почему язык запросов не является императивным, как нормальные яп?
Выше ответили — чтобы дать возможность СУБД самой выбирать оптимальный алгоритм чтобы получить то, что ты там насочинял.
>ибо эта хуйня нихуя не интуитивна
Согласен, но к этой хуйне привыкаешь и она того стоит.
>>139124
По той же причине — чтобы плотили деньги, но только в этот раз не за знание пердольного декларативного языка, а за знание очередных НОВЫХ ФРЕЙМВОРКОВ, которые выходят по одному в месяц.
Всё программирование в капиталистическом мире (я сейчас не осуждаю и не восхваляю капиталистический мир, а просто констатирую печальный факт) неизбежно вырождается в сложность ради сложности, потому что за сложность платят, а за простоту — нет. На эту тему неплохо высказался покойный любитель асма и эффективности https://www.km.ru/referats/778A5D749ACE4041AC2D3D803C05DBBC
>Самолеты и космические корабли мирно сосуществуют с велосипедами и автомобилями. Никому ведь и в голову не придет летать за сигаретами на ракете, особенно если сигареты продаются в киоске на соседнем углу.
>Но ведь это же неправильно! Появление ракет должно перевернуть наше мышление! Поэтому—строим киоск за орбитой Плутона и каждому даем по ракете, чтобы туда летать, а горючее покупаем за деньги, вырученные от строительства космодромов и продаж ракет. Кто не может строить ракеты — пусть учит других, как на них летать. Сколько создается новых рабочих мест и главное, что все в бизнесе. Вот тут уж действительно, возврата в прошлое нет... Сигареты стоят миллиарды долларов, и деньги в индустрию вращаются просто огромные. Кто же захочет от них отказываться?! Напротив, ракеты будут стремительно «совершенствоваться», чтобы за сигаретами можно было летать даже на Альфу Центавра.
Буду кем тебе нравится, сладкий
Собираюсь в конце недели попробовать устроиться по вакансии на джуна.
1)Подскажите, что на собеседовании вообще будут спрашивать? Только синтаксис и умение писать запросы, функции триггеры или всякую теорию тоже лучше запомнить? Как вообще будут проверять, гожусь ли я?
Если что, то в требованиях ничерта особо конкретно не сказано. Просто уровня
> желательно опыт работы с ораклом
> желательно студент последних курсов.
2)Как вообще конторы относятся не к 4ым курсам? Если получится работать как надо, то готов положить на учебу, ибо всё равно бесполезна.
3)Стоит ли пытаться себя как то подать, или просто сказать как есть, что пришёл на первую работу за опытом и кроме вуза и домашней практики за плечами не имею?
4) Немного напрягает, что вакансия висит довольно долго. ЗП вроде не очень маленькая для наших пердей , указана 35-50к.
Каков шанс, что им нужны таки не джуны, или это вообще дутая вакансия?
Извиняюсь за тупые вопросы, никогда не имел дело с собеседованиями.
>Подскажите, что на собеседовании вообще будут спрашивать?
Ну чел, все зависит от конторы и человечности собеседующих. Может ограничится обычными селектами (максимум с аналитическими функциями), может будут спрашивать какие-то общие вещи по БД (что такое нормальные формы) и даже по кишочкам оракла (что из себя представляет B-дерево, как работает hash join). Я бы студента таким ебать не стал, но кто знает.
3 - будь честным, 2, 4 - зависит от конторы. Единственный совет, который я могу дать, это не дропать вышку.
Спасибо за ответы
> Единственный совет, который я могу дать, это не дропать вышку.
Но вот тут хотел бы уточнить: почему?
Из за сложностей уезда из страны?
Просто у меня в группе все наоборот стремятся работать любой ценой, а потом просто на любую доступную заочку платно поступить. Пара человек уже так делает.
БД-макакой ты и так никуда не уедешь. И удаленка на западного барина немыслима, никто не пустит тебя работать с данными.
Про вышку вопрос моих личных предпочтений, я считаю, что она нужна и дает человеку не только корочку, но и общее развитие. И в глазах рекрутеров она значит, что человек хотя бы чего-то добился, а не просто дуриком в айти залетел. В моем рабочем окружении вышка есть у всех (часто еще и топовых вузов).
Вообще, не тема для этого треда, можешь в закрепленном спросить, там будет куча безвышечных макак, которые скажут, что вышка не нужна.
Ага, про собес потом отпиши в этом треде, интересно.
>Подскажите, что на собеседовании вообще будут спрашивать?
Умение писать запросы в первую очередь, но и что посложнее вполне вероятно. Сходи, узнаешь.
-> >>140911
>Как вообще конторы относятся не к 4ым курсам?
Нормально
>Стоит ли пытаться себя как то подать, или просто сказать как есть, что пришёл на первую работу за опытом и кроме вуза и домашней практики за плечами не имею?
2
>Каков шанс, что им нужны таки не джуны, или это вообще дутая вакансия?
Сходи, узнаешь.
Ещё интересно что лучше использовать cross join типо(SELECT P.Part, C.Catnumb AS Cat, C.Price
FROM Parts P, Categories C
WHERE P.Cat = C.Cat_ID)
или такой же запрос с inner join? результат ведь один и тот же
В общем, долго я не мог понять как работают ваши базы данных и вообще веб.
Сейчас восстанавливаюсь после выгорания, и Андроид и веб понял с какой стороны разворачивать, наконец-то дошел и до бд.
Правильно ли я понимаю, что реляционные (от слова математического понятия отношение) БД это то же самое что и табличные? SQL это реляционные БД, noSQL это не реляционные?
Делал свое веб-приложение на основе редактирования таблиц, и сохранял данные в json, предварительно разворачивая все дерево документа в список, чтобы не было самореференсов. Получается что-то наподобие flat file database. Когда файл перевалил за 10 МБ все стало тормозить, и я уже собирался сохранять изменения через file system api, но наконец-то нашел нормальное объяснение и реализации БД, без этих ебучего псевдоязыка sql и с возможностью хранить данные локально.
tinybd + MessagePack. Слава создателям этих двух технологий. Нормальный апи, нормальный из коробки работающий модуль. Я наконец-то понял что такое базы данных!
Дальше я загуглил нечто похожее для js, выбрал localforage.js до тех пор пока окончательно не перенес хранение данных в бэкэнд (которого пока нет).
У меня только один вопрос остался, нахуй тогда вообще файловые системы? Не проще ли все хранить в БД? Может есть такие системы? А то я собирался свою придумать.
Ведь полностью отпадает проблема сохранения изменений, можно сохранять каждое действие пользователя сразу же, как это сделано в Гугл доках.
> Правильно ли я понимаю, что реляционные (от слова математического понятия отношение) БД это то же самое что и табличные? SQL это реляционные БД, noSQL это не реляционные?
Не только таблицы делают реляционные БД реляционными, например, в кассандре тоже есть таблицы, но она NoSQL. Гугли 12 правил Кодда.
> нахуй тогда вообще файловые системы?
Проблемы с перфомансом. СУБД нужны там, где нужна надёжность, пусть и ценой скорости, и нельзя потерять ни одного байта. А представь, что ты копируешь 100 картинок с котиками, и если в конце копирования будет ошибка, ты посмотришь, что недокопировалось, исправишь проблему, и это будет намного быстрее, чем откат транзакции и удаление сотни картинок, когда проблема только с одной.
>Не только таблицы делают реляционные БД реляционными, например, в кассандре тоже есть таблицы, но она NoSQL
А что делает?
>Гугли 12 правил Кодда.
В действительности правила столь строги, что все популярные так называемые «реляционные» СУБД не соответствуют многим критериям. И 13 правил это занудство, никто не умеет считать до стольки. Можно хотя бы 3 обязательных условия, кроме табличного представления данных которые объединяют все 7 реляционных баз из топ-10?
>>132434
Почитай про JOIN.
https://www.postgresqltutorial.com/postgresql-joins/
С твоим запросом у тебя выборка получается, как у inner join.
Т.е. ты выбираешь только те компании, у которых есть телефоны.
Тебе нужен выборка по компаниям с LEFT JOIN телефонов. Тогда выберет даже те компании, где нет телефонов.
ну и группируй соответственно по c.companyId, а не p.companyId
Инсерт селекта по дблинку? Согнать с одной базы в файл и залить в другую? Я за mysql не шарю, но в оракле такие варики есть.
Да хуй блять, эта сволочь за одну дату нормально отрабатывает, а за другую говно жрёт висит.
Если покажешь запрос и план, будет содержательнее, пока хуй знает.
Можешь на шару кинуть хинт ordered, вдруг поможет.
Да из контура нельзя ничего выносить, говорят один умник даже сгуху заработал себе.
Структура простая:
select * from table1 t1
left join table2 t2 on t1.id=t2.id and to_date('01.01.2021')>=t2.start_date and to_date('01.01.2021')<t2.end_date
left join table3 t3 on t2.id=t3.id and to_date('01.01.2021')>=t3.start_date and to_date('01.01.2021')<t3.end_date
left join table4 t4 on t3.id=t4.id and to_date('01.01.2021')>=t4.start_date and to_date('01.01.2021')<t4.end_date
left join table5 t5 on t4.id=t5.id and to_date('01.01.2021')>=t5.start_date and to_date('01.01.2021')<t5.end_date
left join table2 t6 on t5.id=t6.id and to_date('01.01.2021')>=t6.start_date and to_date('01.01.2021')<t6.end_date
where to_date('01.01.2021')>=t1.start_date and to_date('01.01.2021')<t1.end_date
Точно left нужны, inner не катит? На id, по которым идёт джойн, есть индексы? Если id везде одинаковый, попробуй не последовательно таблицу к таблице цеплять, а цеплять каждую таблицу к первой.
left нужны, id разные, там сделка к счёту к клиенту и т. д. цепляется.
Я правильно понимаю, что при вставке данных в таблицу индекс перестраивается каждый раз? Не сьедает ли это производительность?
И чтобы грокнуть тему полностью: индекс перестраивается полностью? Или новое значение для интекса просто вставляется в лситья? Если мы смотрим на него, как на B-tree.
Не полностью, конечно. Ровно настолько, сколько надо для перебалансировки B+-дерева.
Да, поэтому быстрее ебануть большой инсерт, а не много маленьких. Или в транзакции, тогда тоже только при коммите будет.
Запрос вида:
SELECT * FROM `bd`.`table1` ORDER BY `date` DESC LIMIT 1;
Не пользоваться терминалом.
Есть функция TRIM, должно помочь.
Или я долбоёб и в том же tour стрелочки должны идти не к полям, а от полей к таблицам? Тогда они и будут foreign key?
Какого хуя ты не проверяешь сразу при транзакции баланс, если оно тебе так надо.
Если это редкий кейс и не супер критично прям щас, то захуярь какой-то автоматический ежедневный/недельный процесс на проверку качества данных и корректировку.
Всем привет, кто знает что то о таких вакансиях стажеров-аналитиков от сбербанка, ВТБ, озона и тд. сложно ли туда попасть и как проходят?
А как проходила стажировка? Сейчас проходишь еще или уже взяли? Какой уровень sql у тебя был? Платили что то или бесплатно?
А, я дебил, не прочитал про стажировку, я сразу на проект пошёл, к тому времени с базами поработал уже так что взяли без проблем, хинтов я не знал, но всякие там индексы-партиции более-менее одуплял. Могу сказать что народу нехватает сейчас, найм идёт тяжело.
Одновременно со мной пришла баба с эконома, её 2 месяца учили sql перед тем как на реальные задачи пустить, сейчас норм работает. Взять могут, но могут и не взять. Ты надеюсь откликнулся вакансий на 20 хотя бы?
Да сейчас начну отвлекаться. Но я учусь на направлении далеком от баз данных. Смотрят ли на образование?
Ну я пришёл на собес, говорю приветик, я с завода, sql в универе 1 семестр был. Мне дали задачи по sql, я их не решил, мне дали математический задачи уровня олимпиады для пятиклассников, я их решил, мне сказали что за испытательный натаскают на sql и взяли на 50к. Я там немного отработал и съебал в ВТБ. Запускай просто sql-ex и решай, 50 задач решишь, будешь готов к собесу на низкую должность на 100%, вопросы тут можешь задавать посмотри по треду, всем отвечают и тебя не обидят.
Ну я пока 10 решил. И курсы с udemy прохожу. А куда изначально с завода пришел? Что за компания?
Ты ебанулся, анонче? Таких компаний тысячи, та в которой я работал ничего общего не имеет ни с Францией ни со складами.
Я работал на том складе.
Можно ли писать условный бекенд не подключаясь к бд? Получается нужно чтоб то, что выполняется у меня в коде делалось на уровне бд? Как это вообще реализовать? Я из sql знаю основные запросы к бд, а как писать пиоцедуры там с ифами и прочими вещами? Есть ли обучающие материалы, желательно видеоформата.
сап, тема есть;
my sql workbench
бд world
запрос такой:
/
5)Выведите количество официальных языков для каждой
страны в порядке убывания количества этих языков
/
SELECT country.Name, COUNT(Language) AS officialLanguageAmount
FROM country
RIGHT JOIN countrylanguage
ON countrylanguage.CountryCode = country.Code
WHERE countrylanguage.IsOfficial = 'T'
GROUP BY country.Name
ORDER BY officialLanguageAmount DESC;
претензия такая:
нужно также вывести страны, в которых нет официальных языков
я уже голову сломал, как это сделать
Left join вместо right и условие на is official не в where, а в join. И count по какому-нибудь полю второй таблицы обязательно.
Например у меня есть одна шарда какой-то KV базы и у неё стало овердохера данных и я хочу её секционировать на две секции.
Смысл такой что я делю текущую секцию на две и вторую секцию копирую на другую ноду.
Вторая секция лежит в другой части интернета и копирование будет происходить по сети, а значит что долго.
Вопрос:
Как в это время данные пишутся в базу?
Как читаются?
нашел другой способ
/
5)Выведите количество официальных языков для каждой
страны в порядке убывания количества этих языков
/
SELECT country.Name, COUNT(CASE WHEN IsOfficial = 'T' THEN 1 END) AS officialLanguageAmount
FROM country
RIGHT JOIN countrylanguage
ON countrylanguage.CountryCode = country.Code
GROUP BY country.Name
ORDER BY officialLanguageAmount DESC;
Это ок, но у тебя мать сдохнет, если продолжишь пользоваться RIGHT JOIN.
Сейчас по логике, например, у тебя выведется строчка с country name = null, если в таблице countrylanguage есть записи по странам, которых нет в таблице country.
Никто не пользуется RIGHT JOIN, он нелогичен, в твоем запросе основной является таблица country, поэтому джойн должен быть LEFT.
учту, запомню
Чё-т взбрело сделать внутри базы данных - файловую систему.
Не знаю почему, тупо вот в таблице хранить имя файла, его хэш, описание файла, и всё такое, ну и в BLOB'ах - сам контент файла.
Вроде бы, потому что по хэшу проще получить файл.
А ещё, можно было бы, создать файл какой-нить текстовый,
и систему тегов к нему приебошить,
а теги на таблицах сделать, вроде,
ну мол, вот пароль. Он от банка, банк это финансы, финансы это типа бухгалтерия, и всякое такое. Сразу три тега можно приебенить к файлу: банк, финансы, бухгалтерия.
С обычной файловой системой такая хуйня не прокатит, вроде.
А вот в базе данных - можно заебенить.
Есть готовые решения, наподобие этого, с открытым исходным кодом, или придётся SQLite юзать, пушо она опенсорец?
Много чего гуглится, но сам я не тестировал. Отпишись пожалуйста когда что-нибудь выберешь.
Идея сырая поэтому пока вот
Пишет ошибку "#1193 - Неизвестная системная переменная 'GTID_PURGED'".
ID-Фамиля продавца-продажа-время
Мне нужно выбрать последнею продажу по каждому продавцу, но чтоб это работала не всрато.
Когда делаю
select name,max(time)
from govno
group by name
Достаёт всю таблицу, хотя индекса поле со временем есть. Вобщем хуйня какая-то.
sql in 10 minutes глянь. Мне недавно попалась, вполне годная книга по базе.
Пусть есть таблица с буквами.
И пусть есть таблица со словами, состоящими из этих букв.
Обе таблицы связаны, каждый элемент в таблице "слова" - осмысленная единица информации,
которая имеет свой идентификатор, и на которую можно "сослаться", так сказать.
Пусть есть третья таблица "выражения", которые тоже могут быть цельными единицами информации - всякие фразы.
Они уже состоят из нескольких слов, и знаков припинания.
И так далее, и тому подобное. Так, сложность сущностей как-бы растет.
Вопрос, как взаимосвязать всё это попроще, в случае если составных компонентов - произвольное, и возможно даже переменное количество.
Скажем, "хуй" - довольно сложная такая ебанина, состоит из трех букв, но не из шести.
Описание не особо важно, важно только наделить этот хуй идентификатором.
А есть слово "Пизда", у неё уже 5 букв, и она пиздец какая сложная.
Первое, что приходит в голову - создать большую таблицу:
>"Сложные ебанины" (ID, компонент1, компонент2, компонент3, компонент4, компонент5, компонент6, ..., ОПИСАНИЕ)
и там короче сделать null'и компонентов нет.
Можно как-то попроще всю хуйню заебенить?
ID слова,ID буквы
Одна сущность может лежать в неограниченном количестве записей. Описание в отдельной таблице.
Просто я отправил 15 откликов на вакансии , и из них один отказ и одно приглашение на бесплатную стажировку. Это всегда так?
Нашел в 2015 году, всем рекомендую.
Кстати, для стажировки надо быть молодым и иметь вышку, желательно достойную, у тебя как с этим?
Заканчиваю в следующем, техническая вышка,но в другой сфере
Заканчиваю в следующем, техническая вышка,но в другой сфере
SELECT 0 INTO @i;
SELECT (@i := @i+1) AS num,title,text
FROM table1
WHERE
(text LIKE '%earth%' OR title LIKE '%earth%')
Warning:
setting user variables within expressions is deprecated and will
Спасибо, то что нужно
https://www.sqlitetutorial.net/sqlite-select/
пик 1 : шаг один - сложите 1 + 1
пик 2 : поделите 10 на 2
пик 3 ...........
пик 4 поздравляю вы експерт в sqlLite
есть т2 постгрес база на авсе, при чем io1 тобишь с охуевшей пропускной способностью
все крутится, мутится, пока в одном месте бекенда не запускается запрос с группированием/суммированием по паре миллионов строк. Под обычной нагрузкой он выполняется без проблем, так же без проблем он выполняется в обычной, не-рдс базе на слабенькой ec2 машине но именно на рдс базе без какой-то видимой для меня причины он блочит все нахуй, в админке рдса число сессий пробивает небеса, и все последующее запросы тоже залипают до бесконечности в буффере...
я не ебу как это дебажить и где че мерить, мб трабла исключительно в max_connections, ибо сам запрос не ультра тяжелый, мб еще в чем-то, есть идеи?
>ID буквы,Буква
+
>ID слова,ID буквы
>Одна сущность может лежать в неограниченном количестве записей. Описание в отдельной таблице.
Так букв может быть дофига,
что-то вроде:
>ID слова,ID буквы1, ID буквы2, ID буквы3, ..., Описание значение слова.
Ясное дело, что если число букв ограничено (скажем 33 буквы, что в кириллице), то можно просто сделать таблицу с 33-мя полями и не ебать мозг.
Но что если буквы добавляются в таблицу
>ID буквы, Буква
и если это не буквы, а другие составные компоненты сложных сущностей (слов, имеющих ID слова)??
Как всю хуйню попроще увязать?
Ты пишешь
>ID слова,ID буквы
может ты имеешь в виду нечто вроде:
>ID слова,ID'ы букв
?
Что-то вроде
>100500; 23,21,11
??
Тогда, как-бы, до бесконечности можно вхуярить туда буквы.
Но это не связывает сложную сущность с её компонентами, прямыми связями через связи таблиц, поэтому я хз как это всё заебенить, чтоб годно всё было.
Может как-то так, через 3 таблицы:
>"Компоненты": ID компоненты, компонента
>"Сущности": ID сущности, описание сложной сущности.
>"Состав Сущностей": ID сущности, номер компоненты, ID компоненты
Я видимо непонятно выразился, у тебя есть таблица с буквами где есть как минимум айдишник буквы и сама буква, можно туда вкорячить что угодно, описание буквы, также у тебя есть таблица со словами, где слово и описание, описание может состоять из любого количества полей. И в третьей таблице у тебя связь один ко многим, там для одного слова может быть сколько угодно записей со ссылками на буквы, можно номер буквы в слове добавить если нужно.
Посоветуйте книгу по уровням изоляции транзакции и когда какую применять, плз.
>Я видимо непонятно выразился
Да, там какая-то неполная инфа была.
В общем пока получилось пикрил.
Теги - это сложные сущности (слово, фраза).
УникальныеКомпоненты - список атомарных компонент (буквы, слова).
СоставТегов - компонентный состав сложной тегов как сложных сущностей.
Ну и собственно Связи тегов - для взаимосвязи их - многие-ко-многим.
Скажем, тег "нейрокибениматика", состоит из нейронаук, и кибернетики и математики, и связана, блядь, с другим тегом ещё более сложной сущностью - "ассоциативная память с адресацией по содержанию, реализованная на рекуррентных нейронных сетях", которая состоит из ещё большего числа атомарных компонент. Ну ты понел.
Пусть есть хэш-таблица.
И пусть есть некие данные, и хэш от них, в качестве идентификатора их.
Хэши могут иметь коллизии.
Скажем так:
если 1 байт (8 бит),
попытаться сжать в 4 бита и закодировать 4-х битным хэшем,
то будет 2 в 4-й степени (16) коллизий.
Номер коллизии,
всесте с хэшем (4-битным),
дадут 1 байт инфы,
и сжать инфу всё-равно не получится.
Тогда, как лучше было бы однозначно идентифицировать данные?
По номеру, что-ли? А если там все комбинации данных, то номер будет длиной в данные.
Или по паре значений {хэш, номер коллизии}?
Может по самим данны (память с адресацией по содержанию)?
Тогда какой смысл искать данные, по данынм, которые знаешь уже?
Я знаю, что вероятность коллизий хэша может быть низка, при работе с малыми данными,
но всё-же она не исключена. Так, например, файл может иметь тот же хэш, что и текст.
Если коллизий не найдено, можно использовать только хэш, иначе, по хэшу можно было бы выдавать все данные,
с номером коллизии, а для однозначного идентифицирования - хэш + номер коллизии.
Но это только набросок.
В общем, блядь, как бы так попроще, спроектировать базу данных,
чтобы однозначно идентифицировать данные в ней?
Пусть есть хэш-таблица.
И пусть есть некие данные, и хэш от них, в качестве идентификатора их.
Хэши могут иметь коллизии.
Скажем так:
если 1 байт (8 бит),
попытаться сжать в 4 бита и закодировать 4-х битным хэшем,
то будет 2 в 4-й степени (16) коллизий.
Номер коллизии,
всесте с хэшем (4-битным),
дадут 1 байт инфы,
и сжать инфу всё-равно не получится.
Тогда, как лучше было бы однозначно идентифицировать данные?
По номеру, что-ли? А если там все комбинации данных, то номер будет длиной в данные.
Или по паре значений {хэш, номер коллизии}?
Может по самим данны (память с адресацией по содержанию)?
Тогда какой смысл искать данные, по данынм, которые знаешь уже?
Я знаю, что вероятность коллизий хэша может быть низка, при работе с малыми данными,
но всё-же она не исключена. Так, например, файл может иметь тот же хэш, что и текст.
Если коллизий не найдено, можно использовать только хэш, иначе, по хэшу можно было бы выдавать все данные,
с номером коллизии, а для однозначного идентифицирования - хэш + номер коллизии.
Но это только набросок.
В общем, блядь, как бы так попроще, спроектировать базу данных,
чтобы однозначно идентифицировать данные в ней?
Хлебалом щелкни, сам ты ублюдок.
Ты чё тупой, тут же - черным по серому, блядь.
Есть таблица:
>ID, данные
ID - это не что инное как идентификатор.
Что делает ссаный идентификатор? Да ёбана, он же, блядь - идентифицирует!
Идентификацией идентификациональной.
А что же он идентифицирует, а?
ДАННЫЕ, блядь, тупая ж ты бошка! Он идентифицирует - ебучие данные.
Терь, пусть ID'ом, будет хэш, и пусть таблица являет собой хэш-таблицу.
И пусть будет два блока данных, с одинаковым хэшем.
Вуаля - коллизия-хуизия. Дальше, по тексту, сам, снова пройдись.
Если чо непонятно - спрашивай конкретно, и без выебонов своих, дегенератских.
Аноны, когда происходит подключение к базе данных SQLite, грузится ли она в память целиком?
Или только те таблицы, которые запрашиваются, в память прогружаются?
Имеет ли смысл разделить огромную таблицу с многовесными блобами,
на несколько таблиц, и блобы засунуть в одну отдельную таблицу, чтобы жрало меньше памяти?
Или пофиг, и можно в одной таблице всё запилить?
Потому что если без базы данных, просто
>ID, BLOB
если хранить,
то имеет смысл прописать блобы в один файл,
и сделать быстровгрузающийся индекс с оффсетами блобов в этом файле,
и грузить только индекс.
А в сиквелайте как?
> грузится ли она в память целиком?
> Или только те таблицы, которые запрашиваются, в память прогружаются?
Нет, грузится только те ячейки, что запрашиваешь, никакие таблицы целиком не подгружаются. Sqlite - полноценная СУБД, в ней нет подобных подвохов.
> Имеет ли смысл разделить огромную таблицу с многовесными блобами, на несколько таблиц
Не имеет.
> Потому что если без базы данных, просто
> ID, BLOB
> если хранить, то имеет смысл прописать блобы в один файл, и сделать быстровгрузающийся индекс с оффсетами блобов в этом файле, и грузить только индекс.
Не имеет. Как будешь обеспечивать транзакционность, неужели многогигабайтными бэкапами на каждый запрос? Как будешь откатывать данные в консистентное состояние при ошибках ввода-вывода? А оптимизировать обращение к диску как? Решение этих проблем означает изобретение своей СУБД.
>пусть ID'ом, будет хэш,
Вот с этого момента непонятно, сам придумал? Так не принято. Как ты справедливо заметил, коллизии неизбежны, поэтому нельзя завязываться на хэши. Тебе нужен уникальный ID? Бери его из данных или генери инкрементом.
>пусть таблица являет собой хэш-таблицу
Тупое ничтожество, посмотревшее лекцию по алгоритмам на ютубе. Ты понимаешь, что такое хэш-таблица? Размер хэш-таблицы фиксирован!!! Только благодаря этому достигается скорость поиска за О(1)!!! Это невозможно сделать с обычной таблицей в БД!
Мне тебя жалко. Можем сделать вид, что мы друг друга поняли и не продолжать разговор.
>Вот с этого момента непонятно, сам придумал? Так не принято.
Ну, хэш-таблица же, "хэш - значение".
>Как ты справедливо заметил, коллизии неизбежны, поэтому нельзя завязываться на хэши.
В этом и заключалась вся суть вопроса - как правильно это сделать.
>Тебе нужен уникальный ID?
Да.
>Бери его из данных
Как?
>или генери инкрементом.
Если данные добавлять в подобные таблицы, в разной очерёдности,
инкрементируемые идентификаторы будут различными,
и не получится идентифицировать данные однозначно, по этим идентификаторам. Надо че-то более универсальное, например хэш,
но у хэша могут быть коллизии.
Поэтому, пришло в голову, сделать склейку из двух разных хэшей,
что-то вроде id = sha256+md5
но опять же, при длине данных большей чем id, даже у такого id будут коллизии, блядь.
Идеальнейший вариант - идентификатор длиной в данные.
Тогда все комбинации данных заданной битности, можно будет закодировать идентификаторами этой же битности.
Но это не точно, и хуй знает короче, блядь, как это всё организовать заебато. Поэтому я и здесь.
>>пусть таблица являет собой хэш-таблицу
>Тупое ничтожество, посмотревшее лекцию по алгоритмам на ютубе.
Ой блядь, завалил бы ты своё гнилое ебало, прежде чем так дерзко мне чё-то варнякать ИТТ, тупой хуесос.
>Ты понимаешь, что такое хэш-таблица?
Да, блядь, понимаю. Тупо таблица вида "хэш - значение", где значением являются данные, в моём случае.
>Размер хэш-таблицы фиксирован!!!
А у меня нет, и туда могут добавляться данные.
>Только благодаря этому достигается скорость поиска за О(1)!!!
Пиздишь, O(n) в худшем случае.
Вообще, O(1) - это извлечение данных по ключу, в один шаг.
Такое возможно только в отсортированных по хэшам хэш-таблицах,
вгруженных в память.
В противном случае, в неотсортированной по хэшам хэш-таблице, придётся пробегать все хэши, выискивая тот самый.
И хотя в отсортированной по хэшам, хэш-таблице,
возможен бинарный поиск, но это далеко не O(1).
>Это невозможно сделать с обычной таблицей в БД!
Я поэтому и здесь, чтобы узнать, как лучше организовать всю хуйню, в реляционной базе данных, внутри таблицы,
чтобы и скорость была норм,
и чтобы коллизии эти ебучие не ебали потом мозг,
и чтобы вся хуйня в память не вгружалась, а вгружалась только по мере необходимости.
>Мне тебя жалко.
В срачиллиу себе засунь свою жалось ебучую.
Ты так и не ответил на четко-поставленный, мною, вопрос.
>Можем сделать вид, что мы друг друга поняли
>и не продолжать разговор.
Я тебя прекрасно понял. А вот ты меня понял, или нет?
По-моему нет, причем по большей части, особенно в контексте твоего кукареканья, дегенератского.
Разве что по идентификатору у тебя прояснилось. Но это не точно.
>Вот с этого момента непонятно, сам придумал? Так не принято.
Ну, хэш-таблица же, "хэш - значение".
>Как ты справедливо заметил, коллизии неизбежны, поэтому нельзя завязываться на хэши.
В этом и заключалась вся суть вопроса - как правильно это сделать.
>Тебе нужен уникальный ID?
Да.
>Бери его из данных
Как?
>или генери инкрементом.
Если данные добавлять в подобные таблицы, в разной очерёдности,
инкрементируемые идентификаторы будут различными,
и не получится идентифицировать данные однозначно, по этим идентификаторам. Надо че-то более универсальное, например хэш,
но у хэша могут быть коллизии.
Поэтому, пришло в голову, сделать склейку из двух разных хэшей,
что-то вроде id = sha256+md5
но опять же, при длине данных большей чем id, даже у такого id будут коллизии, блядь.
Идеальнейший вариант - идентификатор длиной в данные.
Тогда все комбинации данных заданной битности, можно будет закодировать идентификаторами этой же битности.
Но это не точно, и хуй знает короче, блядь, как это всё организовать заебато. Поэтому я и здесь.
>>пусть таблица являет собой хэш-таблицу
>Тупое ничтожество, посмотревшее лекцию по алгоритмам на ютубе.
Ой блядь, завалил бы ты своё гнилое ебало, прежде чем так дерзко мне чё-то варнякать ИТТ, тупой хуесос.
>Ты понимаешь, что такое хэш-таблица?
Да, блядь, понимаю. Тупо таблица вида "хэш - значение", где значением являются данные, в моём случае.
>Размер хэш-таблицы фиксирован!!!
А у меня нет, и туда могут добавляться данные.
>Только благодаря этому достигается скорость поиска за О(1)!!!
Пиздишь, O(n) в худшем случае.
Вообще, O(1) - это извлечение данных по ключу, в один шаг.
Такое возможно только в отсортированных по хэшам хэш-таблицах,
вгруженных в память.
В противном случае, в неотсортированной по хэшам хэш-таблице, придётся пробегать все хэши, выискивая тот самый.
И хотя в отсортированной по хэшам, хэш-таблице,
возможен бинарный поиск, но это далеко не O(1).
>Это невозможно сделать с обычной таблицей в БД!
Я поэтому и здесь, чтобы узнать, как лучше организовать всю хуйню, в реляционной базе данных, внутри таблицы,
чтобы и скорость была норм,
и чтобы коллизии эти ебучие не ебали потом мозг,
и чтобы вся хуйня в память не вгружалась, а вгружалась только по мере необходимости.
>Мне тебя жалко.
В срачиллиу себе засунь свою жалось ебучую.
Ты так и не ответил на четко-поставленный, мною, вопрос.
>Можем сделать вид, что мы друг друга поняли
>и не продолжать разговор.
Я тебя прекрасно понял. А вот ты меня понял, или нет?
По-моему нет, причем по большей части, особенно в контексте твоего кукареканья, дегенератского.
Разве что по идентификатору у тебя прояснилось. Но это не точно.
Базоданоны, хочу приебенить sqlite3 в наноборду.
Как думаете, норм идея, или лучше оставить прежнюю, костыльную базу данных, на файлах?
https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Database/PostDb.cs#L36
Я не очень силён в проектировании баз данных, только вкатываюсь во всё это дело,
в общем, пока вот:
(Таблица NanoPosts)
id (Primary Key, autoincrement),
, PostHash (text)
, replyTo (text)
, deleted (bool)
, PostMessage (text)
, DateTime (DateTime)
, Pow (text)
, Sign (text)
, NumberOfAttachments (INT)
(Таблица Attachments)
id (Primary Key, autoincrement)
, PostHash (text)
, NumberOfAttachment (int)
, AttachmentHash (text)
, AttachmentFileName (text)
, AttachmentContent(BLOB)
(NanoPosts).(PostHash) < - > (Attachments).(PostHash) - связь 1 ко многим.
Можно ли эту хуйню сделать более заебенчатой, или и так сойдёт?
Базоданоны, хочу приебенить sqlite3 в наноборду.
Как думаете, норм идея, или лучше оставить прежнюю, костыльную базу данных, на файлах?
https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Database/PostDb.cs#L36
Я не очень силён в проектировании баз данных, только вкатываюсь во всё это дело,
в общем, пока вот:
(Таблица NanoPosts)
id (Primary Key, autoincrement),
, PostHash (text)
, replyTo (text)
, deleted (bool)
, PostMessage (text)
, DateTime (DateTime)
, Pow (text)
, Sign (text)
, NumberOfAttachments (INT)
(Таблица Attachments)
id (Primary Key, autoincrement)
, PostHash (text)
, NumberOfAttachment (int)
, AttachmentHash (text)
, AttachmentFileName (text)
, AttachmentContent(BLOB)
(NanoPosts).(PostHash) < - > (Attachments).(PostHash) - связь 1 ко многим.
Можно ли эту хуйню сделать более заебенчатой, или и так сойдёт?
Добрый день, уважаемые специалисты HR.
Буду рад, если моя кандидатура вызовет у Вас интерес и Вы сможете рассмотреть меня на вакансию "Аналитик- стажёр".
Я имею небольшой, но продуктивный опыт в аналитической сфере . Это помогло мне понять окончательно,что я очень хочу продолжать активную работу, обучение и развитие в этом направлении. В своем резюме я указал курсы, которые я успешно прошел, так же я самостоятельно изучаю SQL. Являюсь активным пользователем Excel и Power BI.
В свободное время играю в футбол,люблю музыку и чтение профессиональной и художественной литературы.
От работы жду новых интересных и нестандартных задач.
Благодарю за внимание.
Холуйская манера письма и очень много воды. Уважаемые специалисты эйчар? Это точно не троллинг?
Я бы такое инстинктивно скипал, будучи эйчаркой.
В целом, шаблон сопроводительного письма это гнилая затея, у тебя должно быть максимум про твой опыт и скиллы написано в резюме. А отклик нужен для того, чтобы посмотрели твое резюме, а не для того, чтобы прочли унылый шаблончик и скипнули не открывая резюме.
Если хочешь писать сопроводительные письма, пиши конкретно под вакансию. В вакансии написано "знания технологий X и Y". Ты пишешь сопроводительное письмо "Добрый день! Хотел бы предложить свою кандидатуру на вашу вакансию. Работаю аналитиком столько-то лет, хорошо знаю технологию X, знаком с технологией Y. С уважением, анон". Всё. Без воды и холуйства.
Зачем нужны внешние ключи, если и так джоином все показывается?
Чтобы говняк всякий не вставляли в таблицу. Внешний ключ означает, что ты не можешь вставить в таблицу значение, которого нет во внешней таблице.
А без джоина получается вообще из двух таблиц нельзя посмотреть столбцы? Ну типа я селект всего сделал и sql автоматом выдал результат из двух таблиц сразу по ключу?
Нет, чел.
select * from a, b без условий соединентя вернёт тебе декартово произведение, каждую строчку с каждой.
Если лень писать условия соединентя, есть ещё natural join, которым никто не пользуется. Он джойнит по всем полям, которые одинаково называются. Внешние ключи при этом не используются, вопреки расхожему мнению. Спалил вам секрет на 300к
Какая есть онлайн IDE для MySQL? Вот для Питона есть Replit, для фронтендеров есть Codepen, а что есть для MySQL?
Для прям небольших задач на учебнном курсе.
> Сразу схему я не придумаю, будет меняться по пути
Если схема меняется, пишешь sql-скрипт миграции с нужными правками. Куда меньше головной боли, чем потом на уровне приложения играть в угадайку, в каком формате хранится документ, когда эти форматы менялись, и держать в приложении десятки подходящих загрузчиков.
Посбрасывал все мертвые сессии в пг, psql зашевелился. Потом заглянул в .env и обнаружил там не ту БД.
Сейчас чешу репу, почему не та БД оптимизирована хуже чем та, индексы должны быть одинаковыми. Та БД летает.
Будьте внимательней к своему окружению, да обойдут вас лаги стороной.
Секрет пиздец секретный
Натурал джойном не пользуются и это плохая практика, т.к. его использование создаёт дополнительную точку отказа — надо весь цикл сопровождения теперь следить чтобы у тебя поля одинаково назывались и не появлялось новых полей с одинаковыми названиями в джойнящихся таблицах, а то всё посыпется.
Просто проясняю для не шарящих, не как претензия к тому что ты сказал.
Появилась идея, создать систему личной эффективности, внутри базы данных.
Но я пока не знаю, как лучше всё это организовать.
Что я вижу.
1. Дневник.
Тупо таблица, с записями, и дата там. Что делал, и нахуя, и инфа всякая. В блокноте писать такое не очень удобно, да и читать тоже, когда инфы дофига.
2. Задачи.
Что надо сделать, когда это взбрело в голову, и когда надо завершить задачу + инфа, как именно это делать, ссылки всякие, и так далее.
3. Задачи могут быть огромными проектами, состоящими из множества подзадач, деревьев из задач с подзадачами, и даже сетей из взаимосвязанных задач, блядь.
Как это всё организовать - понятия не имею, может подскажете?
Да, и ещё...
4. В дневнике и задачах - систему тегов бы приебенить.
Чтобы можно было к записям дневника, и записям задач, проектов, и подзадач этих всяких - теги клеить, и по тегам этим быстро находить нужные записи, и что надо бы сделать, ну и собственно - всю инфу внутри них.
Ты сформулируй задачу чётче, тебе надо систему чтобы пользоваться или процесс написания важнее? Если второе то вот посмотри >>159244 что анончик надумал, по сути у тебя такая же многоуровневая структура с задачами и подзадачами. Если первое то вариантов как говна, личная жира это наверное совсем скрам головного мозга, но какую-нибудь канбан доску можно вести онлайн или физически на стене с листочками.
Представим нам нужно сджойнить таблицы A и B по некоторому полю id за 2021 год (где A - таблица фактов с полем даты date). Так вот будет ли второй запрос быстрее?
а) ... FROM A INNER JOIN B ON A.id = B.id WHERE YEAR(date) = 2021
б) ... FROM (SELECT ... FROM A WHERE YEAR(date)=2021) a INNER JOIN a.id = B.id
inb4:
@
IT DEPENDS
ну пусть тогда индекса по дате нет; в обоих таблицах 2 млн строк; SQL Server
>Ты сформулируй задачу чётче
Так это даже не задача пока, а просто черновой набросок, в виде идеи.
Хотя задачу уже вижу, вроде, она как-бы выкристаллизируется.
Задача эта, собственно, в области "проектирования баз данных",
потому что я, пока, даже представить не могу толком структуру БД,
не говоря уж о том, чтобы её создать.
>чтобы пользоваться или процесс написания важнее?
А вариант - написать и пользоваться, не канает штоле?
>Если второе то вот посмотри 2159244 (You) что анончик надумал
Это я и есть, сижу и тыкаюсь втупую, в SQLiteExpertProfessionalPortable
>по сути у тебя такая же многоуровневая структура с задачами и подзадачами.
Вот собственно в этом-то и заключался вопрос.
Как лучше и оптимальнее, организовать всё это, в виде таблиц?
>Если первое то вариантов как говна,
Скорее второе, ну и первое тоже.
>личная жира это наверное совсем скрам головного мозга,
Именно, я хочу что-то вроде личной базы, которая работает локально,
и никуда нихуя не сливает пароли всякие, планы, наработки, и прочую поебень.
>но какую-нибудь канбан доску можно вести онлайн
Чтобы снифферы перехвавали и записывали?
>или физически на стене с листочками.
Опять же, нужно организовать всё это. А как?
>>168165
>Jira
Стремно сливать свои планы хуй знает куда, онлайн, бесплатно и без смс.
>Ты сформулируй задачу чётче
Так это даже не задача пока, а просто черновой набросок, в виде идеи.
Хотя задачу уже вижу, вроде, она как-бы выкристаллизируется.
Задача эта, собственно, в области "проектирования баз данных",
потому что я, пока, даже представить не могу толком структуру БД,
не говоря уж о том, чтобы её создать.
>чтобы пользоваться или процесс написания важнее?
А вариант - написать и пользоваться, не канает штоле?
>Если второе то вот посмотри 2159244 (You) что анончик надумал
Это я и есть, сижу и тыкаюсь втупую, в SQLiteExpertProfessionalPortable
>по сути у тебя такая же многоуровневая структура с задачами и подзадачами.
Вот собственно в этом-то и заключался вопрос.
Как лучше и оптимальнее, организовать всё это, в виде таблиц?
>Если первое то вариантов как говна,
Скорее второе, ну и первое тоже.
>личная жира это наверное совсем скрам головного мозга,
Именно, я хочу что-то вроде личной базы, которая работает локально,
и никуда нихуя не сливает пароли всякие, планы, наработки, и прочую поебень.
>но какую-нибудь канбан доску можно вести онлайн
Чтобы снифферы перехвавали и записывали?
>или физически на стене с листочками.
Опять же, нужно организовать всё это. А как?
>>168165
>Jira
Стремно сливать свои планы хуй знает куда, онлайн, бесплатно и без смс.
Лично я для начала стал использовать формат yaml. Пишу вручную, программа парсит и отображает содержимое файлов в удобном виде. Раньше писал дневниковые записи с временными метками в текстовом виде, потом и их тоже перевел на yaml.
Табличка, есть колонка с датой и дополнительная дата - создания самой записи.
Надо вывести пять последних дат и количество записей с ними, плюс дополнительно количество записей с ними со времени последнего запроса. (это будет вычисляться по дате создания + печеньке с датой визита).
Можно это как-то завернуть в один запрос? Пока сделал первую часть одним запросом простым, а потом в цикле делаю вторую, что колхоз.
Через оконные функции
В чём именно затык? В архитектуре?
>Тупо таблица, с записями, и дата там. Что делал, и нахуя, и инфа всякая. В блокноте писать такое не очень удобно, да и читать тоже, когда инфы дофига.
Таблица с тремя полями: дата, что делал, нахуя делал
>Что надо сделать, когда это взбрело в голову, и когда надо завершить задачу + инфа, как именно это делать, ссылки всякие, и так далее.
То же самое
>Задачи могут быть огромными проектами, состоящими из множества подзадач, деревьев из задач с подзадачами, и даже сетей из взаимосвязанных задач, блядь.
Таблица вида "Задача, внешняя ссылка на задачу" это для связи с подзадачами, на каждую подзадачу у тебя в таблице запись, связывающая задачу-проект с задачей-подзадачей.
Вообще одинаково.
>>171038
>Таблица вида "Задача, внешняя ссылка на задачу" это для связи с подзадачами, на каждую подзадачу у тебя в таблице запись, связывающая задачу-проект с задачей-подзадачей.
Либо, если у тебя строго древовидная-иерархическая система задач, читай не бывает ситуации когда одна задача является подзадачей нескольких других одновременно читай когда не бывает ситуации что некая задача нужна чтобы выполнить более одной родительской задачи, как например "помыть пол" является необходимым и для выполнения "прибраться в комнате" и для выполнения скажем "трахнуть тянку" (которая по какой-то причине у тебя не подразумевает полностью прибраться в комнате, типа чтобы трахнуть тянку в этой комнате тебе достаточно просто помыть пол а вытирать пыль не нужно) можно пойти ещё проще и добавить поле "родитель", являющееся ссылкой на ту же таблицу задач, у нас такое на производстве есть например в применимости материалов.
Типа к примеру сделать выборку через подзапросы или через джоины.
Просто вот в новичковых учебниках(один из которых я дочитываю) ничего про внутринине структуры данных в базах нету и соответственно про сложность алгоритмов по памяти/по времени не очень ясно.
Ну вот некоторые поверхностные вещи про перфоманс при построении схемы, связанные с нормализацией/денормализацией я читал, но это относиться к DDL.
А где описываются вопросы перфоманса для работы с существующими базами(DML)?
Я это изучать не собираюсь, но просто интересно стало насколько глубока кроличья нора в этой сфере.
посмотрел по диагонали что такое планы запроса. и там какие-то баллы, у частей запроса. То есть там все равно не работают с реализацией структур. Это что-то вроде бенчмарка, я правильно понимаю?
Он показывает, что движок бд будет делать для выполнения твоего запроса. И потом можно ручками оптимизировать для его улучшения.
Это более высокий уровень, здесь есть два варианта: бинарный поиск либо поиск перебором. И ещё такие вещи, как например целесообразность искать в маленьком списке, а не в большом. Ну то есть, уменьшить список перед тем, как искать в нём что-то.
Как лучше всего хранить большую двоичную последовательность? С микроконтроллера постоянно приходит набор бит, куда его лучше всего сохранять? Просто в файл сбрасывать? Или для этого как-то удобно приспособить ту же Монгу?
CREATE PARTITION FUNCTION PR ( datetime )
AS RANGE RIGHT
FOR VALUES (
'2010-12-31 23:59:59.997',
'2011-12-31 23:59:59.997',
'2012-12-31 23:59:59.997',
'2013-12-31 23:59:59.997',
'2014-12-31 23:59:59.997',
'2015-12-31 23:59:59.997'
)
Получаю:
Невозможно неявно преобразовать значения диапазона, указанные в параметре под порядковым номером 1 к типу параметра функции секционирования.
что не так со значениями?
;
никогда не имел дел с mssql .
насколько я помню, нигде нельзя опустить партишн в которые добавляются новые значения. то есть граница одной партиции (секции, блядь, специально для неруси) должна быть открыта
эта твоя двоичная последовательность чем характеризуется?
разумеется в файл всегда проще, если ты в пидорахенском нии вундервафли клепаешь.
нормальные программисты о таком и не спрашивают.
Есть база в postgresql, в ней табличка с полями timestamp, bool.
Есть клиенты которые могут одновременно обращаться к базе.
Клиент должен выбрать строку с timestamp <= client_time and not flag, если такая строка нашлась, то переключить флаг и потом еще обновить время.
Важно что бы два и более клиентов не могли получить одну и ту же строку и при одновременном обращении, так же по логике работы подходящей строки в базе может и не быть, в текущий момент.
увольняйся или объясняй кабанчику что ты не шаришь.
Если бы у тебя была нормальная БД вместо мускла, можно было бы извратиться с partial unique index, но это в любом случае костыли и вообще бизнес-логика в БД. Делай на уровне приложения.
не сметь пиздеть на mysql
create trigger before insert on ..
...
select count(id) ...
signal sqlstate '45000' set message_text = 'idite nahooy'
Говно мускул или нет это вопрос.
А вот что
>бизнес логика внутри бд
и
>делай на уровне приложения
Чистая правда
Зачем нужен эластик если можно юзать GIN-индекс в том же Postgres?
что значит "зачем нужен" ?
вайти полно дублирующихся вещей в виде исторических и конкурентной борьбы артефактов.
Как в Постгресе эффективно индексировать boolean-значения?
Клиент-серверная архитектура будет выглядеть так: "Веб-сервер - Сервер БД - БД".
Затребовали конфигурацию сервера БД:
Процессор: такой-то
Оперативная память: столько-то
RAID-контроллер: такой-то
Свободное место на жёстких дисках: 2 ТБ
Правильно ли я понимаю, что отдельно для БД не надо запрашивать конфигурацию? БД как бы выходит в "Сервер БД"?
И еще. Как я понял, мне нужно теперь запросить вторую конфигурацию для Веб-сервера, где будет размещён сам сайт. Всё верно?
>Затребовали конфигурацию сервера БД:
Как затребовали так и оттребуют.
Если вы раньше не эксплуатировали идентичные приложения, то ничего заранее сказать нельзя.
можно только на 3000% умножить твои ожидания и наверняка все будет ок.
Хуй знает что вам там в госах делать. Биржевые аналитики вон проморгали кризис 2008 года, а ты хочешь чтобы тебе на дваче сайзинг бд сделали.
а ну да, как же я забыл!
Объявляешь ЕЩЕ один тендер на НИОКР . И дело в шляпе.
Разве не так дела у вас делаются?
можно так, а можно эдак.
Если это малопосещаемый сайтец для конторы сделанный чтобы было, пожалуй , это даже оптимально.
Эмпирически, с одним сервером - одна проблема, а с двумя - пять проблем.
Нихуя не понял. Но ведь в моём случае же будет два сервера? Один сервер для Веб-приложения (где размещён сайт), а второй - для Сервера базы данных и самой БД.
Есть БД, а есть СУБД, которая управляет БД. СУБД может быть серверной, но не обязательно.
id, reg0, reg1, reg2, count0, count1, count2
Нужно преобразовать в:
id, reg, count
Т.е. было:
1, 10, 12, 15, 2, 2, 1
А будет:
1, 10, 2
1, 12, 2
1, 15, 1
Каким можно так сделать, по мимо экспорта в csv и написание преобразования вручную?
Через insert into ... select ..., например;
insert into mytable (id, reg0, reg1, reg2, count0, count1, count2) select (id, reg0, null, null, count0, null, null) from mytable where count1 is not null and count2 is not null;
insert into mytable (id, reg0, reg1, reg2, count0, count1, count2) select (id, null, reg1, null, null, count1, null) from mytable where count0 is not null and count2 is not null;
insert into mytable (id, reg0, reg1, reg2, count0, count1, count2) select (id, null, null, reg2, null, null, count2) from mytable where count0 is not null and count1 is not null;
delete from mytable where count1 is not null and count2 is not null and count3 is not null;
Похуй, написал парсер уже
Как оказалось. проблема была куда банальнее - по умолчанию в datetime сначала пишется день. а потом месяц, хотя я был уверен, что уже писал в другом формате и всё работало.
> блокировать удаление строки в случае, если на неё ссылаются из другой таблицы
Чем обычный констреинт с внешним ключом не устраивает?
Вы там совсем охуели? Твой труд дешевле установки свежего mysql ?
Нет, ты можешь найти какие-нибудь способы сделать это в процедурном sql, но смысла нет. Посылай своих кабанчиков
Почему нет? Где это ещё считать?
Есть массив данных из селекта в том числе надо посчитать средневзвешеное, если не считать это в скуле, нужно будет передавать весь массив данных чтоб приложение считало, а так сразу все красиво и сгрупировано, в 1000 раз меньщше данных в резалте.
Вот это нужно посчитать
https://ru.wikipedia.org/wiki/Среднее_арифметическое_взвешенное
Если делать через оконные, проебываются остальные агрегации, через две группировки тоже говно какое-то. Наверняка решение где-то на поверхности.
Всем устраивает, но мне именно триггер нужен
>Если делать через оконные, проебываются остальные агрегации,
так если они по одному и тому же окну, почему они проебываются?
Итоговый вывод данных нужен уже сгруппированный, если мы первую задачу решаем через окно, потом при групировке все схлопнется. Там это не единственное вычисление же.
Сделать left жоины трех таблиц потом отфльтровать null
Анон, что такое СУБД?
Давайте рассмотрим это понятие поближе.
Существуют ли СУБД, на самом деле, или же нет?
Конечно же нет.
СУБД - Система управления базами данных.
О каком управлении может идти речь, в принципиально-неуправляемом ебне фаталистичном?
Нет, блядь, и быть не может в принципе никакого "управления", блядь, более того, в объективной реальности, нет и быть не может в принципе никаких "субъектов", которые могли бы чё-то там "управлять".
То, что мы называем "управлением", есть ничто инное как исполнение алгоритма биороботами, и/или программными средствами. О каком управлении, тогда, речь?
Следовательно, нет и быть не может в принципе никаких СУБД.
Таким образом, предлагаю переименовать СУБД в СОБД - Система Обработки Базы данных, или во что-то наподобие оного.
Ты дурачок? Есть база данных, есть система, которая ей управляет - сервер и его обвзяка.
Если это тупо система, то как она может управлять? Она тупо срабатывает, как любая другая система, и нихуя не управляет. Значит это нихуя не система управления, а просто система, которая срабатывает. Не существует управления никакого, это всё пиздёж. Что непонятного, блядь?
Управляет не средство управления, а человек посредством средства управления. Ебать откровение, да?
Ты говорил про "на одном оборудовании", и он соответственно тебе ответил про оборудование. Говоря "два сервера", он имел в виду физически, т.е. два компа на которых крутятся серверные приложения, на одном одно на другом другое. А могут и на одном компе, кто им запретит?
>>184668
Бд это набор нулей и единиц, это данные. Могут быть в файле, могут быть в файлАХ, эти файлы могут быть на одном диске, на двух, на миллиарде, на одном компе, на двух, на миллиарде.
СУБД это программа, которая понимает формат БД. Вот к этому добавлю >>184758 :
>СУБД может быть серверной
из несерверных СУБД навскидку офисные приложухи (вроде) типа ms access и libreoffice base, довольно популярная встраиваемая sqlite3 и файловый режим работы 1с предприятия.
>разруливает блокировки, выбирает планы запроса
не значит что оно управляет.
Но мы не твоя мамка
>>185787
>Управляет не средство управления,
>а человек посредством средства управления.
>Ебать откровение, да?
Так чел - это просто биоробот, который тоже тупо срабатывает по алгоритму, в объективной реальности не существует субъектов, способных в действительности что-то там "управлять", а значит не существует никакого "управления".
Так что выкиньте нахуй это лживое слово из аббревиатуры, оно же вводит всех в заблуждение, не?
> Так чел - это просто биоробот, который тоже тупо срабатывает по алгоритму, в объективной реальности не существует субъектов, способных в действительности что-то там "управлять", а значит не существует никакого "управления".
У человека по умолчанию есть свобода воли. Сначала сходи в /ph/ (а лучше в /psy/ или /me/) и докажи обратное, затем уже сри здесь сколько вылезет. Иначе репорт за оффтоп.
>У человека по умолчанию есть свобода воли.
>докажи обратное
Коль ты пиздишь, то ты и докажи что она есть.
Детерминизм исключает наличие выбора, и свободы выбора, а значит и воли и свободы воли: https://ru.wikipedia.org/wiki/Детерминизм Фатализм, который следует из необратимости и неумолимого течения времени - тем более.
Как выбрать все таблицы из бд кроме одной
SHOW TABLES FROM database NOT LIKE 'users';
При этом с LIKE работает и выбирает одну.
Нашел
Пусть есть таблица с ветвлением (id, parentID, info), в которой есть дерево.
Вопрос: Каким запросом можно извлечь N ветвей дерева?
Годный ответ, но непонятный. Хотя при такой нечеткой постановке вопроса, возможно это самое лучшее что можно было ответить.
Пожалуй, уточню конкретно.
Пусть есть дерево:
х
у
й
н
я
б
л
я
и таблица с ветвлением:
| id | parentID | info |
| 1 | 0 | х |
| 2 | 1 | у |
| 3 | 0 | й |
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
| 7 | 5 | л |
| 8 | 6 | я |
Как сделать рекурсивный запрос с уровнем 3,
на селект элементов "х", "у", "й", "н", "я", чтобы "б", "л", "я" не выводилось вообще, потому что оно где-то там, уже после 3.
Это - относительно нуля 3.
А если относительно 1, или 2, надо 3 уровня извлечь,
то какой тогда SQL-запрос надо?
Не вдуплю вообще как работать с этим WITH RECURSIVE.
Годный ответ, но непонятный. Хотя при такой нечеткой постановке вопроса, возможно это самое лучшее что можно было ответить.
Пожалуй, уточню конкретно.
Пусть есть дерево:
х
у
й
н
я
б
л
я
и таблица с ветвлением:
| id | parentID | info |
| 1 | 0 | х |
| 2 | 1 | у |
| 3 | 0 | й |
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
| 7 | 5 | л |
| 8 | 6 | я |
Как сделать рекурсивный запрос с уровнем 3,
на селект элементов "х", "у", "й", "н", "я", чтобы "б", "л", "я" не выводилось вообще, потому что оно где-то там, уже после 3.
Это - относительно нуля 3.
А если относительно 1, или 2, надо 3 уровня извлечь,
то какой тогда SQL-запрос надо?
Не вдуплю вообще как работать с этим WITH RECURSIVE.
Ответ ожидаю такой:
>Старт=0, depth=3
| 1 | 0 | х |
| 2 | 1 | у |
| 3 | 0 | й |
| 4 | 2 | н |
| 5 | 3 | я |
>Старт=1, depth=3
| 2 | 1 | у |
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
>Старт=2, depth=3
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
| 7 | 5 | л |
| 8 | 6 | я |
В первой части рекурсивного запроса добавляешь столбец счётчик с начальным значением, во второй части прибавляешь к нему единицу, проверяешь в условии его значение
Та дай нормальный запрос, сукка, я ибал весь этот синтаксис пердолить. Нихуя не понятно по ангельски, какие-то схемы ебучие, какие-то Union, With, хуй знает что ещё. Мне же просто надо извлечь 3 ветви ебучего дерева, а не красноглазить неделями над этим сиквелом, ну ёбанарот.
>я ибал весь этот синтаксис пердолить
Палю лайфхак - пиши на чём умеешь. Select from ; и дальше ищешь что тебе надо ручками на жс, питоне, чём хочешь.
Да, нахуй тот движок бд, индексы и прочую душноту. Качай гигабайты говна и молоти в похапе.
На работе предлагают мигрировать в облако (только Azure) и хотелось бы сделать грамотно.
мало удалёнки
много гемора, ответственности и могут заставить ебошить, когда все остальные уже видят сны или накатывают стакан вкусного вискаря в барчике
хреново со сменой работы
>зачем дба?
Думаю, мне это поможет в дальнейшей карьере. Научусь всякую хуету делать, а не просто запросы и етли писать.
>>191953
>>191956
Да ну ёбанарот, пасаны! Я же впостил таблицу вам, блядь...
Ответьте же, просто - рабочим сиквель-квери и ебись рот всей этой ебучей конструкции.
Вы хоть видели сколько матчасти, на ангельском, нужно грызть, и ещё и вдуплить, чтобы только построить этот грёбанный рекурсивный запрос?
Какие-то with, какие-то union, блядь, какие-то условия ебучие, и таблицы - таблицы в примерах совсем не те.
Просто три ветки извлечь надо и не более. Нахуй мне маны все эти колупать с букаффами-то, непонятными?
Ты даже не пытался ничего найти. Вот здесь в примере как раз твой случай, нужно только добавить фильтр по нужному уровню. https://habr.com/ru/post/27439/
Даблять ну ебать-копать, вы можете мне дать нормальный SQL-запрос или не можете?!!
Твой пример нихуя не пашет с первых же строк (пик1).
С горем пополам, добавив FK вручную, сделал эту долбанную-передолбанную табличку (пик2),
думал что вот вот запашет этот запрос. А вот хуй - нихуя не пашет, блядь.
Ты кого наебать пытаешься? Что это за наебалово скамное такое?
Где мой грёбанный запрос, быстро гоните запрос, ещё вчера.
Вот хуясе чё нарыл: https://newbedev.com/creating-a-list-tree-with-sqlite
Вроде даже робит.
Только как эти точки превратить в строчки - хуй знает, блядь.
И вообще, задача стояла получить 3 уровня, начиная с заданного, если вы помните...
Может можно как-то проще, без рекурсии этой хитромудровыпиханной?
Как-то, блядь, селект, потом для каждой строчки ещё по селекту, и так далее и тому подобное - три раза подряд, блеать?
Как? Просто JOIN или INNER JOIN, И что в условии ON написать? Дайте готовый запрос уже блядь, ну хули мне их составлять самому, если я нихуя не шарю в этом SQL?
>create table if not exists tree_sample (
> id integer not null primary key
>);
>
>ALTER TABLE [tree_sample] ADD COLUMN id_parent INTEGER REFERENCES tree_sample(id);
>ALTER TABLE [tree_sample] ADD COLUMN nm varchar(31);
>
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(0,null,null);
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(1,0,'х');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(2,1,'у');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(3,0,'й');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(4,2,'н');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(5,3,'я');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(6,4,'б');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(7,5,'л');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(8,6,'я');
>
>SELECT *
>FROM tree_sample AS level1
>JOIN tree_sample AS level2
> ON level2.id = level1.id_parent
>JOIN tree_sample AS level3
> ON level3.id = level2.id_parent
>WHERE level1.id = '0' OR level1.id = level2.id_parent OR level3.id = level2.id_parent
>
-> ХУЙНЯ, БЛЯ
>create table if not exists tree_sample (
> id integer not null primary key
>);
>
>ALTER TABLE [tree_sample] ADD COLUMN id_parent INTEGER REFERENCES tree_sample(id);
>ALTER TABLE [tree_sample] ADD COLUMN nm varchar(31);
>
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(0,null,null);
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(1,0,'х');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(2,1,'у');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(3,0,'й');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(4,2,'н');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(5,3,'я');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(6,4,'б');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(7,5,'л');
>INSERT INTO tree_sample (id, id_parent, nm) VALUES(8,6,'я');
>
>SELECT *
>FROM tree_sample AS level1
>JOIN tree_sample AS level2
> ON level2.id = level1.id_parent
>JOIN tree_sample AS level3
> ON level3.id = level2.id_parent
>WHERE level1.id = '0' OR level1.id = level2.id_parent OR level3.id = level2.id_parent
>
-> ХУЙНЯ, БЛЯ
Нужно сначала в рамках каждой группы найти персону с наибольшем количеством баллов, а потом собрать все баллы из группы и передать этой персоне. Ну то есть условно у нас есть Вася и Петя в группе 1,у Пети больше баллов, значит оставляем строчку Петя 6. Чот ни как не могу сообразить, сплошное говно и костыли получается.
У меня норм вроде
select t1.nm,t2.nm,t3.nm
from [dbo].[tree_sample] as t1
left join [dbo].[tree_sample] as t2
on t1.id=t2.id_parent
left join [dbo].[tree_sample] as t3
on t2.id=t3.id_parent
>БД, которая работает с одним локальным файлом вроде sqlite
sqlite
>но с возможностью одновременного доступа нескольким пользователям
sqlite
+chmod 666
>чё за дбо? из банка, что ли, капчуешь?
>>194730
>нет, не из банка, dbo же это стандартная схема mssql
Ясно, я просто заменил [dbo] на [main], и оно заработало.
>>194583
Смотри что вылазит (пик1). Сама таблица - на пик2.
>>194726
>Вобще честно говоря я не понял нихуя что ты хочешь, какая бизнес задача так сказать.
>Очень похоже что тебе просто нужна пагинация, а ты какую-то хуйню придумываешь.
Вот смотри. Есть наноборда. И есть формат поста:
>PostHash = ReplyToHash+PostMessage
И есть таблица:
|PostHash|ReplyTo|PostMessage|
Нанопостом может быть тред, или категория.
Грубо говоря, PostHash - это id, ReplyToHash - это id_parent, PostMessage - это инфа (из предыдущей таблицы).
Ну так вот, из этой таблицы, надо выгрузить - 3 уровня ответов, по заданному хэшу.
Скажем так. Пусть имеется хэш поста-категории.
Значит, надо, получить в ответе - сам пост с категорией,
список ответов к этому посту - список тредов,
и списки ответов в треды эти - сам посты в тредах.
Ответы получаются как-то вот так:
https://github.com/username1565/nanoboard/blob/dev/nanodb.exe-source/Database/PostDb.cs#L974
И если прихуярить SQLite, то надо бы SQL-запросом из базы доставать всю эту хуйню.
Понял, да?
З.Ы. Так нихуя и не пашет ваш сиквель-запрос, блядь.
>чё за дбо? из банка, что ли, капчуешь?
>>194730
>нет, не из банка, dbo же это стандартная схема mssql
Ясно, я просто заменил [dbo] на [main], и оно заработало.
>>194583
Смотри что вылазит (пик1). Сама таблица - на пик2.
>>194726
>Вобще честно говоря я не понял нихуя что ты хочешь, какая бизнес задача так сказать.
>Очень похоже что тебе просто нужна пагинация, а ты какую-то хуйню придумываешь.
Вот смотри. Есть наноборда. И есть формат поста:
>PostHash = ReplyToHash+PostMessage
И есть таблица:
|PostHash|ReplyTo|PostMessage|
Нанопостом может быть тред, или категория.
Грубо говоря, PostHash - это id, ReplyToHash - это id_parent, PostMessage - это инфа (из предыдущей таблицы).
Ну так вот, из этой таблицы, надо выгрузить - 3 уровня ответов, по заданному хэшу.
Скажем так. Пусть имеется хэш поста-категории.
Значит, надо, получить в ответе - сам пост с категорией,
список ответов к этому посту - список тредов,
и списки ответов в треды эти - сам посты в тредах.
Ответы получаются как-то вот так:
https://github.com/username1565/nanoboard/blob/dev/nanodb.exe-source/Database/PostDb.cs#L974
И если прихуярить SQLite, то надо бы SQL-запросом из базы доставать всю эту хуйню.
Понял, да?
З.Ы. Так нихуя и не пашет ваш сиквель-запрос, блядь.
select t1.group,t2.maxname,summa
(select group, sum(points) summa from
table group by group) t1 join (select group, name maxname,points, row_number() over (partition by group, name, order by points desc) okonka from table) t2
on t1.group=t2.group and t2.okonka=1
Какое-то такое говно получилось, скорее всего оно даже не запустится так как затестить негде толком, но логику думаю можно понять.
Правильно ли я понимаю, что одну звезду нужно создавать под отдельный источник? Или нет?
Если я правильно понял что ты назвал звездой, и что ты подразумеваешь под источником, то нет. Я так понял отталкиваться надо от сущности.
Источник это какой-то левый сервис, данные из которого нужно забрать из двх. Звезда - это структура таблиц, в которой куча справочников смотрят на таблицу фактов
Так ты и источника грузишь какую-то залупу, клиентов например, в моём понимании это сущность. Если такой сущности у тебя в базе нет - ебашишь новую, если есть, надо хуярить в существующую, скорее всего придётся поебаться с ЕТЛ.
>Если такой сущности у тебя в базе нет - ебашишь новую
А если у меня есть 'продажи' из двух разных источников. И если бы я делал звезду на каждый из них они бы отличались пятью атрибутами.
Я могу создать две звезды, или добавить в старую звезду 5 атрибутов, сделать их налл для старого источника, и записать значения из новго.
Как правильней?
Второй вариант. Тебе потом из этой ебалы витрины строить, всё равно объединять придётся. идентификатор системы-источника обязательно прихуярь ко всем сущностям.
Да спасибо анончик, понял.
типо сначала ебашим по хардкору групбай, чтоб найти сумму, а потом делаем жоин через окно, только топ 1 практиканта, и таким образом получаем имя.
Блядь, хуй от вас дождёшься вменяемого ответа. Сам решил через 4 селекта с UNION.
>Старт=0, depth=3
| 1 | 0 | х |
| 2 | 1 | у |
| 3 | 0 | й |
| 4 | 2 | н |
| 5 | 3 | я |
>Select
>from tree_sample
>where id_parent = "0"
>UNION
>Select
>from tree_sample
>where id_parent = "1"
>UNION
>Select
>from tree_sample
>where id_parent = "2"
>UNION
>Select
>from tree_sample
>where id_parent = "3"
>Старт=1, depth=3
| 2 | 1 | у |
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
>Select
>from tree_sample
>where id_parent = "1"
>UNION
>Select
>from tree_sample
>where id_parent = "2"
>UNION
>Select
>from tree_sample
>where id_parent = "3"
>UNION
>Select
>from tree_sample
>where id_parent = "4"
>Старт=2, depth=3
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
| 7 | 5 | л |
| 8 | 6 | я |
>Select
>from tree_sample
>where id_parent = "2"
>UNION
>Select
>from tree_sample
>where id_parent = "3"
>UNION
>Select
>from tree_sample
>where id_parent = "4"
>UNION
>Select
>from tree_sample
>where id_parent = "5"
вроде пашет, осталось терь оптимизировать всю хуйню, походу.
Блядь, хуй от вас дождёшься вменяемого ответа. Сам решил через 4 селекта с UNION.
>Старт=0, depth=3
| 1 | 0 | х |
| 2 | 1 | у |
| 3 | 0 | й |
| 4 | 2 | н |
| 5 | 3 | я |
>Select
>from tree_sample
>where id_parent = "0"
>UNION
>Select
>from tree_sample
>where id_parent = "1"
>UNION
>Select
>from tree_sample
>where id_parent = "2"
>UNION
>Select
>from tree_sample
>where id_parent = "3"
>Старт=1, depth=3
| 2 | 1 | у |
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
>Select
>from tree_sample
>where id_parent = "1"
>UNION
>Select
>from tree_sample
>where id_parent = "2"
>UNION
>Select
>from tree_sample
>where id_parent = "3"
>UNION
>Select
>from tree_sample
>where id_parent = "4"
>Старт=2, depth=3
| 4 | 2 | н |
| 5 | 3 | я |
| 6 | 4 | б |
| 7 | 5 | л |
| 8 | 6 | я |
>Select
>from tree_sample
>where id_parent = "2"
>UNION
>Select
>from tree_sample
>where id_parent = "3"
>UNION
>Select
>from tree_sample
>where id_parent = "4"
>UNION
>Select
>from tree_sample
>where id_parent = "5"
вроде пашет, осталось терь оптимизировать всю хуйню, походу.
Даже так, не "могут меняться", а "меняются"
Тебе нужна справка по синтаксису select/update, или в чём твой вопрос?
Вопрос в том как спроектировать структуру базы под это. Условно есть пациенты и мне следим сколько(в граммах) каждый из них насрал и нассал в день. Нужно в итоге по id пациента(а других данных о пациенте нет и не нужно) получать инфу:
27.10.2021 нассал литр, насрал килограмм
28.10.2021 нассал 3 литра, насрал килограмм
29.10.2021 нассал поллритра, насрал 3 килограмма
...
Две таблицы:
- patients (id (PK), name, ...) - пациенты
- patient_history (id (PK), patient_id (FK -> patients.id), date, feces_amount, urine_amount) - инфа о пациентах
Внезапно ежур сиквель, не?
И космос дб для мажоров. Иногда космос граф.
Блоб хуита для остальных.
Я не ДБА, но чаще всего вижу такое
Ну и что? Раз у тебя такая модель данных, так и делай. Будет таблица patients с единственным столбцом id.
Это пациент насрал тебе на модель данных только что. Нахуя тебе выносить в таблицу с одним столбцом? Ты что ебобо?
Тебе нужна обычная звезда, если у пациентов только ID нет смысла выносить.
Ты можешь сделать два варианта в зависимости от бизнес задачи:
1) id (PK), patient_id , date, feces_amount, urine_amount,update_time) При таком подходе одна строчка в больнице это будет поведение пациента за день
2) id (PK), patient_id , date, action_id,update_time) При таком подходе одна строчка будет одно событие.
create table tree_sample (
id integer not null primary key,
id_parent int,
nm varchar(31)
);
INSERT INTO tree_sample (id, id_parent, nm) VALUES(0,null,null);
INSERT INTO tree_sample (id, id_parent, nm) VALUES(1,0,'х');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(2,1,'у');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(3,0,'й');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(4,2,'н');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(5,3,'я');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(6,4,'б');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(7,5,'л');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(8,6,'я');
declare
@mocha int=3;
WITH govno (id,id_parent,nm)
as
(
select
id,
id_parent,
nm
from tree_sample
UNION ALL
select
t1.id,
t1.id_parent,
t1.nm
from tree_sample as t1
join govno
on t1.id=govno.id_parent
where t1.id<@mocha
)
select * from govno
Ну если нужно стартовать не с начала, ещё один фильтр повесь.
create table tree_sample (
id integer not null primary key,
id_parent int,
nm varchar(31)
);
INSERT INTO tree_sample (id, id_parent, nm) VALUES(0,null,null);
INSERT INTO tree_sample (id, id_parent, nm) VALUES(1,0,'х');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(2,1,'у');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(3,0,'й');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(4,2,'н');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(5,3,'я');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(6,4,'б');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(7,5,'л');
INSERT INTO tree_sample (id, id_parent, nm) VALUES(8,6,'я');
declare
@mocha int=3;
WITH govno (id,id_parent,nm)
as
(
select
id,
id_parent,
nm
from tree_sample
UNION ALL
select
t1.id,
t1.id_parent,
t1.nm
from tree_sample as t1
join govno
on t1.id=govno.id_parent
where t1.id<@mocha
)
select * from govno
Ну если нужно стартовать не с начала, ещё один фильтр повесь.
>>196833
>@mocha int=3;
не пошет
>WITH govno (id,id_parent,nm)
Бля, ваще не тот результат.
>Ну если нужно стартовать не с начала, ещё один фильтр повесь.
Какой нахуй фильтр? Ты думаешь я разбираюсь в этих ваших фильтрах? Я чо базоданник дохуя из какого-нибудь датацентра пентагона. Дайте же нормальный запрос ну ёбана.
Может как-то каскадом select'ов вытащить все id и сделать потом where id_parent in (selected ids)?
Ну разве тебе не пикрелтйтед нужен? Только офк не весь, а по фрагментам, согласно стоп и старт?
Надо запрос, чтоб достать из таблицы базы данных - все ветви дерева в виде дочерних записей - до нужной глубины, в частности 3, включая родительскую запись.
Вот эта шняга вроде пашет: >>194558
но там 4 union'a, блядь,
и их id'ы - нужно указывать явно.
А надо сделать так, чтобы их не надо было указывать явно, эти id'ы
потому что хуй знает какие они.
Короче, вот:
>CREATE TABLE IF NOT EXISTS [main].[posts](
> [PostHash] TEXT PRIMARY KEY NOT NULL ON CONFLICT IGNORE UNIQUE ON CONFLICT >IGNORE,
> [ReplyToHash] TEXT REFERENCES [posts]([PostHash]),
> [info] TEXT
>) WITHOUT ROWID;
>
>INSERT OR REPLACE INTO [posts]([PostHash], [ReplyToHash], [info])
>VALUES
>('0', '0', '0'),
>('a', '0', 'х'),
>('b', 'a', 'у'),
>('c', '0', 'й'),
>('d', 'b', 'н'),
>('e', 'c', 'я'),
>('f', 'd', 'б'),
>('g', 'e', 'л'),
>('h', 'f', 'я')
>;
[posts].[PostHash] и [posts].[ReplyToHash] - это хэши, а не числа. Это же идентификаоры (id's) родительских и дочерних постов.
Собственно, при указании произвольного поста,
надо выгрузить 3 ветки дочерних ответов к нему.
Список ответов к нему,
список ответов к этим ответам,
и список ответов к ответам этих ответов.
Всю хуйню соединить в одну таблицу, и вернуть её.
Глубина выводимого под-дерева - 3, но она не привязана к хэшам.
Хэши вообще неизвестны, чтобы их явно указывать,
как в этом примере с тремя union'ами: >>194558
они могут быть любыми, и это не числа, чтобы их сравнивать с каким-то числом.
Тупо три уровня надо вывести, я не знаю, блядь, как ещё объяснить эту хуятину ебучую.
Надо запрос, чтоб достать из таблицы базы данных - все ветви дерева в виде дочерних записей - до нужной глубины, в частности 3, включая родительскую запись.
Вот эта шняга вроде пашет: >>194558
но там 4 union'a, блядь,
и их id'ы - нужно указывать явно.
А надо сделать так, чтобы их не надо было указывать явно, эти id'ы
потому что хуй знает какие они.
Короче, вот:
>CREATE TABLE IF NOT EXISTS [main].[posts](
> [PostHash] TEXT PRIMARY KEY NOT NULL ON CONFLICT IGNORE UNIQUE ON CONFLICT >IGNORE,
> [ReplyToHash] TEXT REFERENCES [posts]([PostHash]),
> [info] TEXT
>) WITHOUT ROWID;
>
>INSERT OR REPLACE INTO [posts]([PostHash], [ReplyToHash], [info])
>VALUES
>('0', '0', '0'),
>('a', '0', 'х'),
>('b', 'a', 'у'),
>('c', '0', 'й'),
>('d', 'b', 'н'),
>('e', 'c', 'я'),
>('f', 'd', 'б'),
>('g', 'e', 'л'),
>('h', 'f', 'я')
>;
[posts].[PostHash] и [posts].[ReplyToHash] - это хэши, а не числа. Это же идентификаоры (id's) родительских и дочерних постов.
Собственно, при указании произвольного поста,
надо выгрузить 3 ветки дочерних ответов к нему.
Список ответов к нему,
список ответов к этим ответам,
и список ответов к ответам этих ответов.
Всю хуйню соединить в одну таблицу, и вернуть её.
Глубина выводимого под-дерева - 3, но она не привязана к хэшам.
Хэши вообще неизвестны, чтобы их явно указывать,
как в этом примере с тремя union'ами: >>194558
они могут быть любыми, и это не числа, чтобы их сравнивать с каким-то числом.
Тупо три уровня надо вывести, я не знаю, блядь, как ещё объяснить эту хуятину ебучую.
>>196895
>select *
>from posts as mainPost
>join posts as level0 on [level0].[ReplyToHash] = [mainPost].[PostHash]
>join posts as level1 on [level1].[ReplyToHash] = [level0].[PostHash]
>join posts as level2 on [level2].[ReplyToHash] = [level1].[PostHash]
>join posts as level3 on [level3].[ReplyToHash] = [level3].[PostHash]
>where [mainPost].[PostHash] = '0'
Не?
>>193812>>194557>>194558>>194583>>194802>>196292>>196832>>196862
>>196876>>196871
Ебать, никто не вывел, а я наконец-то вывел это ебучее дерево, вот таким вот ебическим каскадом из селектов:
>CREATE TABLE IF NOT EXISTS [main].[posts](
> [PostHash] TEXT PRIMARY KEY NOT NULL ON CONFLICT IGNORE UNIQUE ON CONFLICT IGNORE,
> [ReplyToHash] TEXT REFERENCES [posts]([PostHash]),
> [info] TEXT
>) WITHOUT ROWID;
>
>INSERT OR REPLACE INTO [posts]([PostHash], [ReplyToHash], [info])
>VALUES
> ('0', '0', '0'),
> ('a', '0', 'х'),
> ('b', 'a', 'у'),
> ('c', '0', 'й'),
> ('d', 'b', 'н'),
> ('e', 'c', 'я'),
> ('f', 'd', 'б'),
> ('g', 'e', 'л'),
> ('h', 'f', 'я')
>;
>
>SELECT
>FROM posts
>WHERE PostHash
>IN
>(
> WITH level1
> AS
> (
> WITH level0
> AS
> (
> select PostHash from posts as mainPost where [mainPost].[PostHash] = @start
> )
> select from level0
> union
> select PostHash from posts where posts.ReplyToHash in level0
> )
> select * from level1
> union
> select PostHash from posts where posts.ReplyToHash in level1
>);
на вход - только один стартовый элемент подаётся, записывающийся в @start.
>>193812>>194557>>194558>>194583>>194802>>196292>>196832>>196862
>>196876>>196871
Ебать, никто не вывел, а я наконец-то вывел это ебучее дерево, вот таким вот ебическим каскадом из селектов:
>CREATE TABLE IF NOT EXISTS [main].[posts](
> [PostHash] TEXT PRIMARY KEY NOT NULL ON CONFLICT IGNORE UNIQUE ON CONFLICT IGNORE,
> [ReplyToHash] TEXT REFERENCES [posts]([PostHash]),
> [info] TEXT
>) WITHOUT ROWID;
>
>INSERT OR REPLACE INTO [posts]([PostHash], [ReplyToHash], [info])
>VALUES
> ('0', '0', '0'),
> ('a', '0', 'х'),
> ('b', 'a', 'у'),
> ('c', '0', 'й'),
> ('d', 'b', 'н'),
> ('e', 'c', 'я'),
> ('f', 'd', 'б'),
> ('g', 'e', 'л'),
> ('h', 'f', 'я')
>;
>
>SELECT
>FROM posts
>WHERE PostHash
>IN
>(
> WITH level1
> AS
> (
> WITH level0
> AS
> (
> select PostHash from posts as mainPost where [mainPost].[PostHash] = @start
> )
> select from level0
> union
> select PostHash from posts where posts.ReplyToHash in level0
> )
> select * from level1
> union
> select PostHash from posts where posts.ReplyToHash in level1
>);
на вход - только один стартовый элемент подаётся, записывающийся в @start.
Не, я скорее про сам процесс.
Читал про Azure Data Factory. По документации все слишком радужно выглядит, что мол подключился к базам и всем чуть ли не само выгрузилось в какой-нибудь дата лейк.
Чую в реальной жизни там ведро вазелина должно быть на готове.
А как вывести все ветки, без depth=3 ?
И как посчитать, для заданного родителя,
на базе всех веток,
число самых глубоких элементов дерева,
которые не имеют детей?
Вполне себе тривиальная задача, хули.
Выгрузить все нанопосты в треде, и подсчитать их: https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Server/DbApiHandler.cs#L140-L141
С этими двумя моментами сложности.
А пока вот что наварганил - черновой вариант (пикрил).
Ну так сделай ее сам епта. Раз такая тривиальная.
Охуеть, школото-кабанчик в треде?
Что-то требует от всех, хуйми кроет, а само даже пояснить что ему надо нормально не может.
Что тебе непонятно? Тривиальная же задача, ебать. Вот есть ветка, надо выгрузить и вывести из таблицы-ветвления, все другие ветки от неё пиздующие, найти ебучие листики, показать их, и подсчитать их число. Для вас это должно быть тривиально, пушо вы шарите в базоданности, а я ебу весь этот синтаксис пердолить с этими всякими WITH, RECURSIVE блядь, AS, UNION, JOIN, ON, ебать копать сколько всего ещё там. Доки мне суёте, блядь, ещё бы ссылку на учебник по SQL вхуярили. Дайте нормальный запрос же ну?!!
Чел ты упускаешь что обычно этим людям за их знания и умения какие-то деньги платят.
Если бы я возжелал купить ебучий запрос, я бы пошёл на биржу труда и купил бы его, блядь.
Они просто нихуя не шарят в базах данных, разве это не очевидно?
Вот моё решение.
SELECT distinct maker
FROM product inner join
(
SELECT distinct model
from
(
SELECT model, ram, speed
FROM pc
WHERE ram = (SELECT MIN(ram) FROM pc)
) as q
WHERE speed = (SELECT MAX(speed) from
(
SELECT model, ram, speed
FROM pc
WHERE ram = (SELECT MIN(ram) FROM pc)
) as q )
) as q
on product.model = q.model
WHERE
maker in (
SELECT maker
FROM
product
WHERE type = 'printer')
Вот моё решение.
SELECT distinct maker
FROM product inner join
(
SELECT distinct model
from
(
SELECT model, ram, speed
FROM pc
WHERE ram = (SELECT MIN(ram) FROM pc)
) as q
WHERE speed = (SELECT MAX(speed) from
(
SELECT model, ram, speed
FROM pc
WHERE ram = (SELECT MIN(ram) FROM pc)
) as q )
) as q
on product.model = q.model
WHERE
maker in (
SELECT maker
FROM
product
WHERE type = 'printer')
Я-то со своими друзьями так не поступаю.
А если что-то и прошу, то во-первых на то должна быть веская причина, а не "мне лень гуглить", а во-вторых постараюсь предложить денег (потому что друзей я ВНЕЗАПНО уважаю) или как-то еще отплатить. Если твои друзья поступают с тобой иначе, то это не друзья, а пидоры, ну а если ты сам так поступаешь с друзьями, то пидор ты, а они долбоебы.
Мне вон некоторое время назад друг просил матери его на др цветов купить, потому что 1 он находится в двух тысячах км от места действия и 2 мать его живет в деревне куда доставку не заказать. Чуешь разницу между его просьбой и своей? а еще он мне денег предлагал, в отличие от сам знаешь кого
>>199374
>>199376
Какой же занудный капиталистоблядок приебался ко мне.
Нихуя не предложил, зато хочет жидовского говна - недоденех.
Мань, у меня недоденьхи в крипте. но я тебе не то что не дам её, а даже не покажу. А знаешь почему? Да потому, что стоит вам, антагонистичным пидарасам капиталистоблядским, показать, или хотя-бы намекнуть, где именно держишь котлету, так сразу вы всё изговните, назло, лишь бы не дать распродать эту срань. Нахуй иди со своими недоденьгами, здесь технологии обсуждаюотся, блядь.
Дайте ебучий запрос, ну ёбанарот.
Можешь ограничения вкорячить чтобы нельзя было выписать раньше чем прописать и прописать кого-то в номер где есть жилец.
Можно всё сделать одной таблицей, где будут номер, дата и тип действия, например 0 - заселение, 1 - выселение.
Делшь одной таблицей, но когда делаешь вставку заселение, в поле выселение ставишь NULL. Если человек выселяется, заполняешь выселение. Таким образом тебе для обновления из таблицы нужно будет запрашитвать только строки с NULL.
SELECT wheel.id, wheel.name, COUNT(car.id) AS vehicles_count
FROM wheel
LEFT JOIN car ON (car.wheelsize = wheel.wheelsize)
WHERE wheel.id = 42
И всё бы ничего, но если нет ни одного автомобиля, соответствующего условию joina, ответ пустой, а не с vehicles_count = 0, как должно быть. Как сделать чтобы выборка не запарывалась при невыполнении джойна?
Даже не пойму что у гугла спрашивать...
Ты мне не дашь — я тебе не дам.
>здесь технологии обсуждаюотся, блядь
Конкретно ты здесь не технологии обсуждаешь, а ищешь работника по найму, но отказываешься платить. Пшел вон.
>Table |id|parentID|info|
>id - Primary Key, unique, not null
>parentID - foreign key для id
Как сделать INSERT INTO для записи с каким-то parentID, которого нет в id?
Пишет Foreign constraint failed, блядь.
Либо сноси foreign key, либо добавляй запись с таким ID. Ты не можешь просто взять и послать нахуй ссылочную целостность.
>Как сделать INSERT INTO для записи с каким-то parentID, которого нет в id?
Никак. Ты как себе это представляешь?
Если у тебя код родителя это внешний ключ, то будет работать проверка целостности, что означает, что ты именно что не сможешь вставить запись с ключом, которого не существует. Разжалуй код родителя в обычное поле, либо создавай соотв. запись.
Можно, собственно через триггер.
Делаешь триггер before insert для своей таблицы, смотришь на добавляемую запись и делаешь инсерт в свою таблицу с ID равным parent_id из добавляемой записи, parent_id равным null, info равным какому-нибудь значению по умолчанию, возможно, тоже null. Но инсерт делаешь не всегда, а только если предварительный селект ничего не найдёт, либо через какой-нибудь MERGE или INSERT ... ON CONFLICT DO NOTHING, смотря что за СУБД.
>>199982
Понял. Заебенил вот так, в сиквелайте:
>PRAGMA foreign_keys = 'off';
>
>INSERT OR IGNORE INTO NanoPosts (PostHash, ReplyToHash, PostMessage)
>VALUES ('TestHash', 'HashNotExists', 'TestHashMessage');
>
>PRAGMA foreign_keys = 'on';
Никакой хуйни не вылазит, при этом.
>>200193
А это, походу, можно, можно сделать с помощью
INSERT OR IGNORE INTO
уже потом.
P.S.: Или даже до:
>CREATE TRIGGER [main].[InsertRowIfPrimaryKeyNotExists]
>BEFORE INSERT ON [NanoPosts]
>WHEN [NEW].[ReplyToHash] != (
> SELECT [PostHash]
> FROM [NanoPosts])
>BEGIN
> INSERT OR IGNORE
> INTO [NanoPosts] ([PostHash])
> VALUES ([NEW].[ReplyToHash]);
>END;
>>199982
Понял. Заебенил вот так, в сиквелайте:
>PRAGMA foreign_keys = 'off';
>
>INSERT OR IGNORE INTO NanoPosts (PostHash, ReplyToHash, PostMessage)
>VALUES ('TestHash', 'HashNotExists', 'TestHashMessage');
>
>PRAGMA foreign_keys = 'on';
Никакой хуйни не вылазит, при этом.
>>200193
А это, походу, можно, можно сделать с помощью
INSERT OR IGNORE INTO
уже потом.
P.S.: Или даже до:
>CREATE TRIGGER [main].[InsertRowIfPrimaryKeyNotExists]
>BEFORE INSERT ON [NanoPosts]
>WHEN [NEW].[ReplyToHash] != (
> SELECT [PostHash]
> FROM [NanoPosts])
>BEGIN
> INSERT OR IGNORE
> INTO [NanoPosts] ([PostHash])
> VALUES ([NEW].[ReplyToHash]);
>END;
И ещё такая шняга имеет место быть. Мудро?
Бле, а как быть с этим триггером,
если вставляется куча записек с пронумерованными rowid?
При срабатывании триггера, когда он триггерится,
вставляется rowid со значнением rowid'a в insert or replace into,
а потом оно, это insert or replace into - заменяет ту запись что создал триггер,
и опять пишет фореигн констрайнт файлед, блядь.
Удалил нахуй ровид поле, теперь какого-то хрена не все записи вставляются, и всё глючит, и зависает, и ещё и жрёт дохуя памяти. Пиздец просто.
Понял, надо удалить ON DELETE CASCADE, потому что insert or replace into срабатывает как два действия - DELETE и INSERT,
и когда производится insert or replace into (rowid, id, IDParent), и id с IDParent нет в таблице, срабатывает триггер, добавляющий id с этим же rowid, а попытка его реплейснуть, сначала удаляет всё нахер, и удаляется оно КАСКАДНО, включая инсертртную запись,
а потом инсертится другая хуйня, на место вставленного триггером id.
Там надо поставить что-то вроде do nothing, и ебись оно конём.
Выше тред посмотри, этой залупе уже подсказали куда копать, но оно хуями кроет и требует решения.
Ебало завали, червь. Думай над рекурсивным иерархическим запросом лучше.
Хуй дождёшься вменяемого ответа от вас,
недоспециалисты, с купленными дипломами, блядь.
Проще самому накостылить, ке-как работающий говнокод.
Например, что-то вроде:
>CREATE TABLE [NanoPosts](
> [IsDeleted] BOOL DEFAULT False,
> [PostHash] TEXT PRIMARY KEY NOT NULL ON CONFLICT IGNORE UNIQUE ON CONFLICT IGNORE,
> [ReplyToHash] TEXT REFERENCES [NanoPosts]([PostHash]) ON DELETE NO ACTION,
> [PostMessage] TEXT) WITHOUT ROWID;
>
>CREATE TRIGGER [InsertRowIfPrimaryKeyNotExists] BEFORE INSERT ON [NanoPosts] WHEN (SELECT COUNT ([PostHash])
> FROM [NanoPosts]
> WHERE [PostHash] = [NEW].[ReplyToHash]) == 0
>BEGIN
> INSERT OR IGNORE INTO [NanoPosts]
> ([PostHash])
> VALUES ([NEW].[ReplyToHash]);
>END;
Хуя пожар. Платить-то будешь?
Ему теперь все бесплатно. Зашел в магазин, набрал всего и идешь без оплаты. Заебись, мне бы так.
Но у меня не спиздили деньги. Или спиздили, но я этого не знаю? Тогда давайте лучше деньгами сразу.
Ок, только натурой отработай вперед :3
Пока так: https://github.com/username1565/nanoboard/blob/nanodb-sqlite/nanodb.exe-source/Database/nanodb.sqlite3.sql
А дальше хуй знает что делать с этим, набросал пару планов тут: https://github.com/username1565/nanoboard/issues/17
стажёр - кто знает теорию, но нет опыта работы
джун - опят работы от года
ты - пустое место, от которого одни проблемы
В шепот
>>201404
ЯП? Вообще вводная туманная, разработчик баз данных в смысле разработчик СУБД? СУБД не так много, конкретика будет в вакансиях предприятий, которые их разрабатывают.
Или в смысле "вот я прихожу в тырпрайз и пытаюсь решить его проблемы с помощью БД"? Ну тогда конкретика будет в вакансиях бизнесов, которые хотят решать свои проблемы с помощью БД.
https://www.datacamp.com/search?q=&tab=courses&facets[technology][]=SQL
Там всегда 85% скидос.
Я по студенческой подписке могу 3 месяца бесплатно пользоваться.
Книги - круто, но я про курсы спросил.
Ну я пошерстил вакансии, требуют знания sql, субд каких-нибудь типо oracle/mysql, знания ооп, с этим вроде проблем нет, но почти везде требуют корочку или последнии курсы, это отсутствует, вот мне и интересно есть ли здесь те, кто залетел на работу с первых курсов, но у меня есть еще опыт работы бекендером на пистоне, может это как-то поможет хотя опыт был, всего в пару месяцев.
Вопрос - как сократить и сделать запрос PostgreSQL более удобным?
Пишу
select
case when (куча-куча условий...) as a,
case when (куча-куча условий...) as b...
Возможно ли a и b как-то прописать в начале запроса, чтобы в селекте я мог написать "a-b", а не "case when (...) - case when (...)"?
Поясни ущербному, как с помощью with сделать?
Подзапросом попробую, джойн не нужен в этом случае, кажется.
1. Написал процедуру/вьюху;
2. Провести анализ плана выполнения;
3. Построить архитектуру связей;
4. Знать оконные функции;
Дополните, хочу упороться по уши в БД - книги читать влень, тасков по сиквелу хуй да нихуя. Начал гуглить запросы ака Advanced sql - CTE, cross join - плевая хуйня, правда рекурсивных CTE и их применения так и не нашел. Сейчас ебусь с XML, JSON в Sql.
Жажду познаний на уровне поддержки проекта в соло, но не знаю в какую сторону клюв мочить.
Спасибо.
я реально не знаю, какие задачи ставят DBA. Через SolarWings посмотреть медленные запросы? Провести анализ для вертикального/горизонтального масштабирования? Практики нет нихуя. Я бы еще с репликациями/партеционированием поигрался, вот только негде.
Еще вопрос к знатокам MsSql - если проебался с транзацией и по случайности юзер въебашил Update/delete в прод, как можно сделать откат транзакции? Ведется ли журнал или только последней transaction Id?
Слушай, что-то я запутался, может подскажешь.
есть 4 колонки в mysql:
колонка 1, колонка 2, ip, время
Мне нужно выбрать:
ВСЕ пары колонок 1 и 2, встречающиеся максимальное количество раз за последнюю неделю, НО с уникальным ip
Если я пытаюсь делать subquery в WHERE (выбираю всё дубликаты ip за последнюю неделю, например), то идёт потом фулскан таблицы и я не ебу как победить это.
Я заебался, анон, выручай ((
Аноним 08/11/21 Пнд 04:29:29 №22063502
ну типа все уникальные пары колонок:
значение 1 - значение 2
значение 1 - значение 3
сортировка по частоте пар.
я на грани того, чтобы разделить всё на 2 запроса, сначала выбрать все уникальные ip, а потом по ним сделать:
SELECT колонка 1,
колонка 2,
COUNT(*) AS Count
FROM search
WHERE createdAt > (NOW() - INTERVAL 7 DAY)
GROUP BY колонка 1, колонка 2
ORDER BY Count DESC
Аноним 08/11/21 Пнд 04:30:18 №22063523
но я хочу в одном запросе всё заебенить, помоги, а, пажалуста
Аноним 08/11/21 Пнд 04:34:24 №22063564
я мудак. короч если я в FROM пытаюсь сделать подзапрос с выборкойуникальных - то где-то вылезает фулскан, вот что я имел в виду.
а так не должно быть или я кривой мудила, я не понимаю уже. и так и так и джоинами хуеинами пытался - не получается избежать фулскана
Слушай, что-то я запутался, может подскажешь.
есть 4 колонки в mysql:
колонка 1, колонка 2, ip, время
Мне нужно выбрать:
ВСЕ пары колонок 1 и 2, встречающиеся максимальное количество раз за последнюю неделю, НО с уникальным ip
Если я пытаюсь делать subquery в WHERE (выбираю всё дубликаты ip за последнюю неделю, например), то идёт потом фулскан таблицы и я не ебу как победить это.
Я заебался, анон, выручай ((
Аноним 08/11/21 Пнд 04:29:29 №22063502
ну типа все уникальные пары колонок:
значение 1 - значение 2
значение 1 - значение 3
сортировка по частоте пар.
я на грани того, чтобы разделить всё на 2 запроса, сначала выбрать все уникальные ip, а потом по ним сделать:
SELECT колонка 1,
колонка 2,
COUNT(*) AS Count
FROM search
WHERE createdAt > (NOW() - INTERVAL 7 DAY)
GROUP BY колонка 1, колонка 2
ORDER BY Count DESC
Аноним 08/11/21 Пнд 04:30:18 №22063523
но я хочу в одном запросе всё заебенить, помоги, а, пажалуста
Аноним 08/11/21 Пнд 04:34:24 №22063564
я мудак. короч если я в FROM пытаюсь сделать подзапрос с выборкойуникальных - то где-то вылезает фулскан, вот что я имел в виду.
а так не должно быть или я кривой мудила, я не понимаю уже. и так и так и джоинами хуеинами пытался - не получается избежать фулскана
У него это есть в списке.
Понятно, что если сначала наапдейтить, то типа данные будут дерти и полочит все.
Ты ж Spring-макака, хуле
Недавно выяснил что мой коллега жавист не знает SQL дальше команды SELECT, ни про индексы, ни про подзапросы ни про джойны блять он нихрена не знает
Это всё из-за говнохибернейта.
Добрый день аноны прошу помощи на коленях.
Есть запрос
select from [t0] where eid in (
select [t1] from [t1] where [t1].person_id = 12321321
)
Так вот. Вложенный запрос возвращает ID-шники и я отдаю их на вход оператору IN. Этот запрос выполняется 3 секунды. Но в тоже время если я вместо вложенного запроса напрямую передаю id-шники то запрос выполняется сразу же (т.е)
select from [t0] where eid in (
345435345,
435435435,
154353342,
121212132,
)
Я сломал голову почему в первом случае запрос выполняется 3 секунды а во втором сразу же. Прошу помощи на коленях!
Сори ошибся в текстовке
Первый запрос :
select from [t0] where eid in (
select id from [t1] where [t1].person_id = 12321321
)
Второй:
select from [t0] where eid in (
345435345,
435435435,
154353342,
121212132,
)
Зайка, ну, вложенному запросу тоже надо кушать процессорное время, чтобы выдать тебе готовые айдишники
Отдельно он выполняется мгновенно в том то и дело!
Результат один и тот же, а как лучше/быстрее?
Вроде во втором случае нестед луп 100% похаваешь, а в первом можно хинт прописать или планировщик сам получше способ выберет, но я долбоёб, в оптимизации плохо шарю.
Твоя говнотранзакция может удерживать лок на строчках или даже целиком на таблице
Это какие-то пряники с быстрых спринг-курсов для долбоебов. У меня все наоборот - умею низкоуровнево шлепать через SQL (JDBC), но понятия пока не имею о хибере и прочих ОРМ.
Кстати, сам по себе спринг не обязательно значит использование ORM. Ты можешь в DAO-классах юзать хоть что, хоть сериализацию в файлы.
мимо-джавоблядь
Настоящий специалист в это (да что уж там, в любой) ситуации уклонится от предсказания.
Померяй, заебал.
ну надо же, язык, который призван скрывать от программиста все эти сложности, довольно часто их скрывает успешно!
кто бы мог подумать..
(нет, это все вполне ожидаемо и даже хорошо)
Джава то призвана скрывать? В сравнениии с чем? С сями что ли? Ты просто пользуешься ей поверхностно, видимо
Забей, терминологию всегда придумывают шизики, которым изначально это казалось логичным, а потом просто прижилось.
Не могу, да я даже смысла его не понимаю. Всегда 2 сущности, клиент-сервер, мне достаточно клиента, чтобы коннектится к серверу. Зачем мне драйвер? Есть у меня psql, я ввожу необходимые опции и аргументы, все, могу работать.
Драйвер - это либа, которую ты дергаешь из своего кода, чтобы дернуть базульку
Драйвер нужен для того, чтобы у тебя была одна либа с стандартным интерфейсом, а сам драйвер реализует уже работу с конкретным сервером базы.
тебя ебет вообще?
Этот термин старше тебя.
Так повелось уж.
https://metacpan.org/pod/DBI::DBD#CREATING-A-NEW-DRIVER
>Аноним
Когда аноним пиздит бабло у анонима, то аноним торчит анониму, так что не залупайся мне тут и гони мой SQL запрос, а то двойку поставлю, и завалю тебе сессию, да так что не сможешь составить даже резюме, лентяй необразованный. Элементарные вещи сделать не может, зато засел в базоданном треде и мнит из себя хуй знает что, нихуя не шаря притом. Лол.
Здравствуйте.
Вам ответит Сертифицированный Специалист !
Чтобы не проебать данные используйте стратегии: CYA и PITR !
Подробности Вы найдете в Google.
Спасибо за вопрос!
спасибо. PITR нагуглил, а вот CYA не могу найти. И я так понял PITR - это обычный ажуровский бэкап?
CYA - это юмор такой. Cover Your ASS.
Под PITR обычно подразумевается ручное накатывание лога на один из недавних бекапов.
Возможно, в Ажуре это уже автоматизировано настолько что все в ажуре. Конкретикой по mssql не владею.
Судя по картинкам, все там ок https://azure.microsoft.com/ru-ru/blog/azure-sql-database-point-in-time-restore/
Разумеется, ничего не мешает сделать это заранее и вручную. Ведь все мы знаем что облако - это просто чужой компьютор!
Триггер с проверкой, что ему передали именно NULL, и последующей установкой нужных значений. Но лучше так не делать.
>Но лучше так не делать.
Почему? А как делать?
Это же инкапсуляция, безопасность, уверенность в завтрашнем дне, член 21см.
При создании столбца ты указываешь, что в нём будут храниться int, и c этого момента ты уверен, что даже аллах не засунет туда varchar. Если что-то пойдёт не так, тебе и в голову не придёт подумать, что в одном из столбцов число записано как строка, а не как число - потому, что это невозможно.
Потом ты создаёшь primary key на основе столбца и с этого момента ты уверен, что в этом столбце никогда не будет двух одинаковых значений. Твой толстый 13-сантиметровый член стоит колом, ведь ты - доминант, и созданная тобой структура данных надёжно защищена.
Но вот ты делаешь столбец auto_increment и больше ты ни в чём не уверен, уже на следующий день приходит ехидная тётя Зина из бухгалтерии и записывает туда свой день рождения. Этому никак нельзя помешать? Это же язык для бухгалтерш, он наоборот должен быть напичкан защитами от дурака.
ты не прав. SQL - язык для Оператора ЭВМ.
Оператор ЭВМ в 1970-ом году имел два высших образования и выглядел примерно так.
Это вузовское задание, и мы только начинаем изучать бд, поэтому всё довольно упрощено, да и + к этому есть некоторые обязательства по типу: "Должны быть минимум одна связь M:N и 1 поле с фото".
Ты подразумеваешь, что БД - это некая отдельная очень важная сущность, содержание которой имеет значение само по себе и что очень важно, что там лежит в конкретный момент времени - строка, число, автоинкремент или еще что. Я тебе открою секрет: это не так, и БД - это просто сучка основного приложения, т.е сучка бизнес-логики и сама по себе она значения не имеет. В сучке будет лежать то, что в нее засунет альфач, если альфачу нужно всунуть id в обход маняинкремента, то он всунет. Если альфачу захочется поменять тип данных и держать числа в виде строк, то он поменяет и будет держать. А что ты сделаешь, пукнешь и попросишь соблюдать твои маняправила потому что тебе так будет приятнее?
мне кажется рейс где-то не там. Билет не пришей пизде рукав, у тебя нет таблицы фактов, надо начинать с неё строить, представь как как выглядит одна строчка таблицы фактов, а вокруг неё строй справочники, чтоб получилась звезда\снежинка.
Ну, если воспринимать sql как грязную суку, которую в любой момент можно завалить в клумбу, трахнуть и уйти не попрощавшись, то возможно. Но, во-первых, это делает взаимодействие с ней менее приятным - я предпочитаю более порядочных женщин. Во-вторых, мне каждый раз приходится передавать ей null, чтобы она вспомнила, что у неё там автоинкремент на столбце стоит.
Можно периодически заглядывать в бордель, но жить с тупой шлюхой не захочется.
Как сделать в одном селекте соединить два и более селектов разных таблиц? Что-то типа такого нужно получить:
(SELECT FROM table_1 WHERE id = ) + (SELECT FROM table_2 WHERE id = AND status = )
На выходе я получаю жсон где мне нужно иметь массив из первой таблицы, плюс не связанный с ним массив из другой таблицы.
Union
Пик очевидно не работает, потому что в IN(...) приходит строка
Очевидно заменить в аргументах процедуры тип ids с text на массив (text[]. integer[], uuid[], etc), все остальное вроде ок
Добрый день, хочу вкатится в IT и выдрочить чисто sql. Можно ли будет, обладая только знаниями в бд, иметь возможность зарабатывать? Просто, в свое время, изучал все это в шараге и мне показалось, базы данных, довольно простыми, для изучения, правда это было давно и сейчас я уже мало, что помню.
Алсо, если я хочу написать зародыш ускоспециализированной ERP в качестве пет проджекта с перспективой его дальнейшей доработки до ума, запуска на сервере и использования 3,5 человеками, имеет ли смысл в начале на десктопе юзать SQLite и уже потом перекатываться на что-то повеселее, когда (если) оно пойдёт в веб, или лучше потратить пару лишних вечеров и сразу какой-нибудь MySQL в качестве БД использовать?
Можно. Только знать придётся га том уровне, где нифига не просто. Как минимум, писать хранимые процедуры.
мне нужно не для работы, а для собесов
что-то меня на последнем размазали тем, что начали спрашивать о том, как работает mvcc, как устроена репликация, что такое b-tree (бля, вот позор, я был уверен, что там обычное бинарное дерево поиска) и прочий бред
как будто мне как простому разрабу это может понадобиться
хотя стоит признать, интересно почитать какие-нибудь статьи/видосы о внутренностях и устройстве базки
ну и если по перечисленным трем топикам я могу прочесть отдельные статьи, то инетерсует какие еще есть странные и прикольные штуки внутри бд
Помню про работу Vacuum, AutoVacuum спрашивали. Что происходит, когда делается DELETE. Бери любую книгу по PostgreSQL с хорошими отзывами, там обычно именно про устройство, конфигурирование и пишут. Либо ищи книги именно с Deploy/Configure/for DevOps в название.
Разумеется, я до сих пор жду свой сиквель-запрос, и поскольку вы у меня на счетчике уже, то с каждой наносекундой просрочки, будете торчать мне на 20% больше должного сиквель-запроса, разумеетяс с учетом реинвеста процентов.
>Фильтры выноси в where.
Как? :C
UPDATE [dbo].[Pollers] p
INNER JOIN [dbo].[Volumes] v on v.VolumeID = p.NetObjectID
SET p.Enabled = 'False'
WHERE p.NetObjectType = 'V'
AND v.VolumeID IN (3533, 3532, 3531, 3530)
Ищу какое-нибудь визуальное средство проектирования БД. Прицел на SQLite, но было бы хорошо иметь и поддержку чего-нибудь "взрослого".
Требования:
- Свободное ПО, не онлайн-редактор;
- Нормальный машиночитаемый вариант сохранения проектов или готовые генераторы кода для ORM.
Из симпатичного вижу pgModeler, но он чисто для Postgres, как я понял.
Она разве свободная?
Уже знаю силекты, группировки, функции встроенные всякие и иннеры джойны.
Этого хватит.
UPDATE [dbo].[Pollers] p
SET p.Enabled = 'False'
WHERE p.NetObjectID IN (
SELECT p1.NetObjectID FROM [dbo].[Pollers] p1
INNER JOIN [dbo].[Volumes] v1 on v1.VolumeID = p1.NetObjectID
WHERE p1.NetObjectType = 'V'
AND v1.VolumeID IN (3533, 3532, 3531, 3530)
);
Можешь еще подзапрос в CTE вынести
2)Почему в марии такой ебанный оптимизатор запросов? В постгресе тоже самое? в оракле и мускуле вроде норм
> 1) Можно ли в марии явно указать какой из фильтров where применять первым?
Костылями с CASE WHEN THEN.
Какой же ты ебанат.
Нет, нельзя. Нельзя в декларативном языке указать что выполнять первым.
Но ты можешь написать подзапрос в скобочках.
>Я не использую скобочки
а надо бы :)))))
по сути, единственный способ задать зависимости в вычислениях sql.
ты ведь этого хотел, да?
Только не говори что хотел последовательного выполнения. Нет никакого последовательного выполнения в SQL.
Послали нахуй в js треде.
Суть вопроса:
Кто сталкивался с postgreSQL ошибкой: неверный синтаксис для типа uuid: "
Я пытаюсь зарегистрировать пользователя, и какого-то хуя, пострге думает, что поле email имеет тип UUID. Как это блять так? Я ничего не менял в entity пользователя. Поле email было и остается строкой, я просто добавил обертку над методом save (который работал до этого просто отлично и всегда создавал пользователя), с логикой регистрации. Если явно указать, что email это text или VARCHAR, то БД просто виснет нахуй, сервер пишет, что соединение невозможно установить. Если убрать из entity email, то регистрация проходит как по маслу, т.е. проблема именно в этом поле. Пиздец, я просто охуел блять.
P.S. Я буду завтра более детально ковырять код, сегодня у меня мозги уже не работают. Для эксперимента спиздил модуль авторизации с гитахаба, точно такой же результат. Почему-то именно поле emai создает проблемы на ровном месте. БД просто нисхуя решает, что это UUID и, в полном праве ругается, что строка вида:
Как схему БД создавал? SQL-скриптом или какой-нибудь очередной ORM? Проверь, какого типа у тебя поле в базе, может, оно действительно у тебя почему-то UUID.
Короче я нашел проблему, она никак не связана с БД. Странно, ORM и серверный фреймворк полностью проигнорировали несоответствие типов в запросе к БД, а отправили запрос как есть. Это меня очень сильно смутило, я получил ошибку не о несоответствии типов или хз о чем на английском от фреймворка, а на русском от БД.
Нужны гайды (желательно видео + отработка навыков) по MS SQL. Очень прям надо. Не спрашивайте почему я не практикуюсь на других SQL, просто пожалуйста помогите мне.
Спасибо
Мне очень помог начать понять азы.
https://infobiza.net/threads/kartavec-video-kurs-osnovy-baz-dannyx-jazyk-sql.27052/
Далее уже гуглил от конкретной задачи.
Если знаешь иностр языки то это ПУШКА!
https://infobiza.net/threads/alexander-schlee-udemy-web-scraping-apis-for-data-science-2021-postgresql-excel-2021.188267/
Пчел, шапка для кого?
"Для каждой специальности сформировать список абитуриентов
набравших проходной балл. В выборке должны присутствовать
следующие поля: название специальности, ФИО студента,
набранные баллы." ?
срок сдачи уже завтра, не могу разобраться. Спасибо.
И хули ты без супа с сиськами пришла, курица?
Пробую различные сочетания distinct, case when, group by, но что-то мне начинает казаться, что средствами SQL это невозможно сделать.
SELECT NUMS.NUM, A.LETTER, B.LETTER FROM (
SELECT DISTINCT NUM FROM MYTABLE
) NUMS
LEFT JOIN MYTABLE A ON A.NUM = NUMS.NUM AND A.LETTER = 'a'
LEFT JOIN MYTABLE B ON B.NUM = NUMS.NUM AND B.LETTER = 'b'
ORDER BY NUMS.NUM ASC
Скинешь сиськи с супом, решу.
ты какой-то хуйни начитался. Принеси сначала ее источник.
Похоже, речь о крайних формах нормализации. Авито действительно этим публично хвалилась. Я даже забыл как точно они называются и тебе советую забыть.
Это не key-value.
Вспомни о чем ты https://habr.com/ru/company/avito/blog/322510/
Ну и хуй с ними. Сначала вырасти до Авито.
> Я даже забыл как точно они называются и тебе советую забыть.
Это 6 нормальная форма, якорная модель называется. Речь не о ней, а том, что в:
>key-value сложно выполнять аналитические запросы
Сказал архитектор яндекс ГО.
А в авито ничего примечательного и сложного нет, лол. Я тоже самое в хадупе для гамбургеров делал.
>Вспомни о чем ты
То что key-value не подходят для олап нагрузки сказал архитектор яндекс го, я завтра это вырежу и скину сюда.
Ещё вопрос - https://habr.com/ru/post/495670/
Юзал кто-нить микросервисное кхд? Хуета или имеет
>То что key-value не подходят для олап нагрузки сказал архитектор яндекс го,
Ну так он и не подходит. С чего ты взял что в avito key-value типа redis? Нет у них не redis для этих данных.
Причем, это не значит что у них нет redis вообще.
лично я нихуя не понимаю что происходит, что такое data lake, зачем так много разных тупых названий и почему нельзя все уложить в реляционные базы.
Похоже, никто ничего не понимает, но данные хранить все равно надо для потомков и поэтому возник data lake.
1. Как часто их проводят? Понятно, что у каждого по своему, но какие практики - раз в сутки/12 часов/каждый час?
2. Как бэкапится база, в фоновом режиме? Если нагрузка на базу идет 24/7, скорее всего schedule будет в пики самого низкого прайм тайма? Много ли ресурсов хавает бэкап?
3. Как долго и где хранятся прошлые бэкапы? Прод базы весят хуеву тучу места, нужно не малое хранилище, чтобы хранить как минимум 10 бэкапов по 50 гбт.
4. В каких реально случаях бэкап спасает? Пиздой накрывается вся база, если да, то как это возможно?
5. Bakpack хранит все данные + индексы? После рестора идет построение индексов?
Знаю, что высрал много вопросов, но реально хочется разобраться, а ответов на вопросы хуй кто дает. Или не хотят шарить или сами не разбираются.
Всем добра.
> С чего ты взял что в avito key-value
Разве там основное Хд не на вертике? Вертика - кей валуе.
>что такое data lake,
Это тоже самое что и хранилище данных, только больше. По хорошему, это помойка куда кидают вообще все данные, в том числе и картинки с видосами.
Все равно не объяснил.
о чем статья?
Это место откуда дата-саентисты надеятся в будущем извлечь что-то полезное, поэтому бизнес вынужден хранить, хоть пока у них ничего не получается ?
Хранить-то навалом попроще будет. Но о чем тогда статья?
как так? я уже приготовился с работы увольняться и канадский язык учить! а что? датаинжеренты везде нужны, ща нехватка, понимать надо!
Судя по вакансиям, тебе надо не столько знать бд, сколько хорошо пердолять на яве/питухоне
ёпта, вон автор курсов в питоне ни в зуб ногой и ничо, укатился
вообще хуею, чо им надо всем? одним субд, другим скалу, третьим набор каких-то хипстерских приблуд...
хз о каких ты курсах, но щас все просят Spark\Airflow, в 9 из 10 вакансий эти говна на дата инженера.
ПОВАР СПРАШИВАЕТ ПОВАРА КАКОВА ТВОЯ ПРОФЕССИЯ
ПОВАР, БЛЯДЬ!
>>227387
Да есть тут один Дмитрий Аношин.
В следствие совпадения обстоятельств и отличного нетворкинга умудряется не зная программирования работать с данными в Канаде.
Пропагандирует идею, что любой повар может перекатиться в Канаду. Нужно просто пройти 50 собеседований и обязательно повезет.
Недавно к нему в телеграме на канале пришел некий банковский архитектор и как давай правду-матку рубить. Очень весело было. Жаль он его забанил.
Ах да, в отличие от мутных инфобизнесменчиков, курсы он не продает. Плана у него нет. Денег ему и так хватает, поэтому он просто может позволить делать себе всякую дичь хаотично.
То есть, обманывает он бесплатно. От чистого сердца.
>ПОВАР СПРАШИВАЕТ ПОВАРА КАКОВА ТВОЯ ПРОФЕССИЯ
>ПОВАР, БЛЯДЬ!
На самом деле, чтобы вкатиться в бд, нужно знать всего-лишь Анси скл. Я 2 года етл разработчиком работаю, айпфлоу, гринплам и т. д. Тоже хочу архитектором стать, вот только хз как...
ну и сколько платят? Простое не может оплачиваться хорошо. SQL ведь не существует в вакууме. Он связан с кучей разных программ и процессов.
Если только реально альтернатива между заводом и офисом.
Причем, на заводе тебя все уважают, а тут будут считать ненастоящим айтишником, которому даже винду нужно показывать как траблшутить.
Когда знал, получал 70к.
Ну давай от противного.
Принеси-ка ссылку на HH где нужно знать только SQL и посмотрим сколько предлагают.
Много ли найдется программистов готовых вкатывать левого чувака который ничего особо не знает?
В большой компании такой может пристроится. Но больших компаний у нас сколько? ДВе. Сбербанк и Газпром.
Ща, разбежался я тут ссылки искать и доказывать. Реально пишешь глупости и хочешь, чтобы с тобой спорили вокруг этого
>Принеси-ка ссылку на HH где нужно знать только SQL и посмотрим сколько предлагают.
https://hh.ru/vacancy/49789043?from=vacancy_search_list&query=SQL
>https://hh.ru/vacancy/49789043?from=vacancy_search_list&query=SQL
T-SQL, оптимизация
>https://hh.ru/vacancy/48652402?from=vacancy_search_list&query=SQL
Полный набор для warehouse
Да, эти люди действительно пользу приносят. Но какую пользу может принести повар-вкатун с одним лишь Ansi SQL?
>оптимизация
Не один ждун не знает оптимизацию. Можно вкатиться на джуна и выучить её.
Тут тоже самое, не знает ждун, который вкатывается что такое олап, а что такое олтп. Это понимание приходит во время работы.
А можно не вкатиться. Давай рассуждать о главных тендециях, а не об исключениях.
Еще раз:
в чем польза бизнесу от sql-джуна, если его работу в 3 раза быстрее выполняет нормальный программист, которого просто сняли на неделю с проекта?
50 собеседований значит нужно пройти?
Ну да ну да ,чистый SQL
И да, если взять долю вакансий, то вот этих синьёров помидоров со скулюм 2 вакансии при том с одной ты обосрался лол, а дата инженеров 200 вакансий.
>в чем польза бизнесу от sql-джуна
Когда я пришёл в компанию джуном только с анси sql-ем я взял на себя всю 3 линию тех. поддержки, я попросил за это 50к, мне сказали, что будут платить 70к. Потом я пошёл на новый проект уже в роле мидла, освоил airflow, разобрался, также как разбирались остальные с хадупом и гринпламом.
>>227512
Нужен очень низкий уровень питона, чтобы освоить airflow и писать на нём ЕТЛ.
>Когда я пришёл в компанию джуном только с анси sql-ем я взял на себя всю 3 линию тех. поддержки
окей. сколько таких вакансий сейчас на hh.ru наблюдается?
https://hh.ru/vacancy/49187766?from=vacancy_search_list&query=sql
https://hh.ru/vacancy/42798543?from=vacancy_search_list&query=sql
https://hh.ru/vacancy/49228353?from=vacancy_search_list&query=sql
https://hh.ru/vacancy/50142989?from=vacancy_search_list&query=sql
И это я только с первой страницы собрал
Там же ещё даги оркестрация, передача туда судапеременны, плюс источники не всегода бд, довольно много пердрлинга. Да и в ЕТЛ как бы есть ещё ТРАНСФОРМ
строго говоря, нуль таких вакансий. ведь тебе 3 года назад дали 70000.
Что-то просветления не достиг, из полезного узнал про IN-Memory таблицы только хзачем, есть же REDIS и как различия в работе жоинов при анализе плана запроса. Но что-то в целом все какое-то слишком мутное, чтоб можно было брать и применять на практике, без особых усилий, куча всякого про устройства сервера и про механизмы, но если бы я этого не знал, не много бы потерял.
Задавайте свои ответы
хуй не сосу, бочку не делаю
>Там же ещё даги оркестрация, передача туда судапеременны
Если для тебя это СЛОЖНА СЛОЖНА НИПОНЯТНО, то я не вижу смысла продолжать дискуссию.
>Да и в ЕТЛ как бы есть ещё ТРАНСФОРМ
В большинстве своём пишется на SQL.
Ну да, они ведь никакие навыки не приобретут и не будут через год - два мидлами. Конечно лучше на завод.
Это толстый тролинг такой?
речь о том что если ты можешь выучить аирфлоу и успешно пердолится с ним в контйнере, надо катится в полноценное погромирование, где и зп больше и вакансий выбор шире
Я могу выучить что угодно, только зачем, если мне и тут норм платят? Может сразу GO учить?
Немного, приходится просрочку жрать, но у меня есть коллеги, которые получают 200 и 250к.
Не троллинг.
Пытаюсь узнать как рассуждают кабанчики.
Неужели такая нехватка кадров имеет место быть?
О, ты то мне и нужен. Как лучше вкатываться воздущный поток? Как там вобще разрабатывать и код писать, дебагать? Он же крутится где-то далеко, а просто подкладывать ему файлы без проверки неудобно наверное. Как запускать вот это все для локльно, из того же пичарма например?
А то вот написал я говнокод, не сразу же выкатывать, позапускать сначала где-то нужно, посмотреть на ошибки.
Я вот буквально только что ради тебя нашёл одну книгу.
https://vk.com/doc255577237_598735863?hash=d0ec40ea846c0f4123&dl=d9ce12e35a07f168e7
>Он же крутится где-то далеко, а просто подкладывать ему файлы без проверки неудобно наверное.
Наверняка как-то можно, но я подкладываю, хотя выгугливал специальные IDE, где его можно потестить.
че ты доебался? откуда нам знать как у тебя на работе делают бекапы?
Устраивайся в Амазон. Там нет секретов.
кроме секрета о том, что все персональные данные спиздили и продали в ЦРУ
я не спрашиваю за себя - спрашиваю как у анона
Падажжи. У тебя какие требования к событиям? Они должны быть прочитаны только одним потребителем? Если да, то в таком случае оба варианты являются опасными, можно продублировать событие.
Есть ли либы на Питон (или любой другой язык), которые позволяют читать данные из дамп-файлов Postgres, не распаковывая их?
а если нет, то зачем это говнище вообще нужно?
Это копия, сохраненная 3 июля 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.