Это копия, сохраненная 14 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Ссылки:
- https://www.postgresqltutorial.com/
- https://www.mysqltutorial.org/
- https://www.sqlitetutorial.net/
- https://www.oracletutorial.com/
- https://github.com/agarcialeon/awesome-database
Задачи:
- https://www.sql-ex.ru
- https://www.codewars.com/?language=sql
Продвинутый MySQL:
- https://www.mysqltutorial.org/mysql-resources.aspx
- https://shlomi-noach.github.io/awesome-mysql/
Инструменты проектирования БД
- https://www.mysql.com/products/workbench/
- https://explain.dalibo.com/
Видосики:
- Плейлисты по разным СУБД: https://www.youtube.com/c/SQLDeveloperBI/playlists
- https://www.youtube.com/playlist?list=PLY7PmJJFH5nT-lbFKxfbp3rw5BBuq5Azo
Литература:
- Томас Кайт. Oracle для профессионалов
- https://postgrespro.ru/education/books/dbtech
- Алан Бьюли. Изучаем SQL. - про MySQL
- К. Дж. Дейт. Введение в системы баз данных
Прочее:
- https://dbdb.io/
- https://db.cs.cmu.edu/
- https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA/playlists
- Сравнение диалектов SQL: http://troels.arvin.dk/db/rdbms/
- Как БД работают изнутри: https://habr.com/ru/company/mailru/blog/266811/
Ссылки для аутистов:
- https://www.w3schools.com/sql/
- https://learnxinyminutes.com/docs/sql/
- https://metanit.com/sql/
- http://sql-tutorial.ru/
- https://metanit.com/nosql/mongodb/
FAQ:
Q: Нужно ли знать английский?
A: Да.
Q: Что лучше, SQL или NoSQL?
A: По задачам.
Q: Вопросы с лабами и задачками
A: Задавай, ответят, но могут и обоссать.
Здесь мы:
- Негодуем, почему шапка - говно, и предлагаем идеи, как её улучшить.
- Разбираемся, почему PostgreSQL - не Oracle
- Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
- Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обеществе
- Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
- Анализируем, как работает поиск вконтакте
- И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно.
Поехали!
Сохранить данные, некритичные к целостности, между сессиями пользователя.
Есть ли реальные преимущества у nosql для oltp баз данных?
Какие преимущества и в каких кейсах?
Только инмемори кей-велью для кешей для меня очевидны.
У клепмана читал преимущества графовых. Он там пугал, что обход графа в реляционках можно заменить рекурсивными сте. Но на деле в них ничего особо страшного не оказалось, для простых кейсов вполне норм. Ну конечно если сложные обходы сложных графов или поиск в них, то да. Еще я слышал, что у графовых проблемы с большими объемами.
Какие преимущества у монги перед jsonb вообще не ясно.
Для olap вот бд колоночные(аналитика) и временных рядов(метрики) намного лучше, чем реляционки.
И вообще анончики, расскажите плиз с какими nosql вы работали и для каких кейсов.
Логи, кеши, настройки, очереди, события, хранилища сырых данных, аналитика. Словом, всё, где скорость важнее транзакционности.
(я мимиоаналитик который хочет перекатиться в DE, так что разница немного значительна. украсть в PDF не предлагайте, учусь лучше с бумаги, чем с экрана)
Я посмотрел пару обсуждений челиков из Тинькова. И там один чел, который начал на русике плевался, перешел вроде на середине на англючик. Я, как быдло прочел на русике и мне норм.
Какое поле лучше сделать в постгре - jsonb или composite type?
Сomposite type вообще кто-то пользуется?
Если эластик как сервис, то там все более менее нормально, главное чтобы кабанчик плотил по счетам. Если это опенсерч или че там форкнутое то земля вам пухом, особенно если придется переезжать из клацдаа
Те же самые что и у РСУБД. Нет смысла в почти 2023 выбирать постгрес или мускул с оракулом. Достаточно монгодб, которая позволяет хранить вложенные сущности, дает тебе ACID транзакции, шардирование из коробки (этого нет в РСУБД) и отличную производительность, т.к. нужные запросы идут в определенные ноды кластера.
Чел, ты не в теме. Просто качаешь эластиксерч с офф сайта и поднимаешь кластер за 10 минут. Твой мутный опенсерч никому не всрался, чел...
Так вот, нужен ли я хоть кому-нить за границе? Меня хоть куда-то с такими навыками возьмут? Хочу жить в тае...
Как думаете, будет ли такое время, когда я смогу работать на Российские компании, но при этом быть богачем в тае?
Пошёл нахуй.
Лет 5 минимум с учётом текущих событий, я ща работу ищу, первый вопрос всегда "а вы часом не съебали?"
Гайз, чё-то туплю спасайте.
SELECT distinct
t1.p,
TRIM(t2 .n1) + TRIM(t2.n2) + TRIM(t3.n3) as n
FROM
table1 t1
JOIN table2 t2 ON t1.p = t2.p
t1.p- varchar(6), t2.p- nchar(6)
Выдаёт ошибку "Character to numeric conversion error"
Пробовал кастить t2.p в varchar но он берёт только первый символ. Если в varchar(6) то выдаёт туже ошибку.
Ты хохол чтоли? Где они собрались брать Табло и PowerBI?
Эластик с Кибаной - это невнятное дрочение. Горя хлебнешь с этой явой. Ява пахнет тленом.
Если у них уже есть опыт - пусть и делают.
Но на перспективу, аналитику я бы хранил в Clickhouse, а визуализировал бы в Superset.
я у мамы аналитик хранилищ, по факту кроме sql нихуя не знаю
Заканчивай под себя срать, чел. Монга дает тебе из коробки acid транзакции, шардинг (которого никогда не будет в постгре или оракле) и еще множество вещей вроде хранения вложенных структур данных в виде жысона. Обтекай, короче.
А в чем проблема шардинг не из коробки к реляционкам прикрутить? Полно же тулзов.
Никаких проблем, но надо же прийти сюда раз в год и пошитпостить про NoSQL, а то скучно слишком.
Msg 1205, Level 13, State 52, Line 3 Transaction (Process ID) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction
И я конечно понимаю, что в процессе выполнения этого селекта другими запросами апдейтятся участвующие в селекте таблицы, но какого хуя и как это с минимальными потерями обойти? В интренете полно советов но нихуя не понятно, какие-то советы про индексы. Какая то мутная UPDLOCK, которая вроде должна заприть апдейты (не надо мне такого), какая-то срань с уровнями изоляции, которые вроде как устанавливаются глобально и воздействуют на все запросы. Какого хуя не могу просто сделать сраный селект без дед лока (например селект с какого-нибудь среза), если апдейты во время селекта меня не итересуют, пусть себе апдейтится на здоровье
Ну тогда OFFSET. Может еще скажешь что SQL в твоем штандарте не уебищный кусок говна (как язык)?
Хорошо, теперь можем поговорить на равных.
ЕБАТЬ ТЕБЯ НЕ ДОЛЖНО БЫСТРО ИЛИ МЕДЛЕННО РАБОТАЕТ SQL
В стандарте ничего про скорость и способ выполнения нет!
это означает, что для ответа на вопрос ПОЧЕМУ тебе придется тебе придется изучать конкретный план конкретной СУБД с конкретными характеристиками конкретных данных.
И задавать такой вопрос на ДВАЧЕ- полностью глупо.
В твоей ситуации по какой-то причине индекс не стал использоваться.
Напиши пиши простейший запрос со SKIP, где он бы использовался и далее усложняй. Убедись что данных достаточно много, потому что у оптимизаторов есть тенденция выбирать полное линейное чтение в случаях, когда данных смехотворно мало - это действительно быстрее.
>Хорошо, теперь можем поговорить на равных.
Поговорим.
>В стандарте ничего про скорость и способ выполнения нет!
Ну это вообще кек, как тогда свитеропетушня должна определять что уже дрищет под себе или еще нет?
>>537270
Я про вот это:
http://use-the-index-luke.com/no-offset
>offset instructs the databases skip the first N results of a query. However, the database must still fetch these rows from the disk and bring them in order before it can send the following ones.
WTF?
Я уже спрашивал вообще то. Ожидаемо двачерская пидорва обдристалась. Но может в этот раз больше повезет
Я кстати когда был таким же молодым петушком так же надрачивал на богом данные ШТАНДАРТЫ-ШТАНДАРТИКИ на золотых скрижалях. W3C, XHTML - вот это все. Правда когда я столкнулся с тем что с doctype происходит какая то лютая хуита не смотря на то что это самая первая строка любого документа а не какая то обскурная хуитка о которой никто не в курсе - вот тут я начал что то подозревать... А вот когда штандарт xhtml2 был официально пидорнут - вот тогда мой манямирок окончательно развалился.
Сейчас я люблю отмечать как некоторые вещи созданные практиками внезапно оказываются значительно адекватнее чем дрисня высратая стандарто-импотентами.
да мне похуй на стандарты, просто не люблю MS SQL.
>Ну это вообще кек, как тогда свитеропетушня должна определять что уже дрищет под себе или еще нет?
Путем анализа фактического плана и статистики выполнения фактического запроса. Или серии запросов.
>Я про вот это:
http://use-the-index-luke.com/no-offset
>>offset instructs the databases skip the first N results of a query. However, the database must still fetch these rows from the disk and bring them in order before it can send the following ones.
Строго похуй что там в MS SQL.
Если ты видишь какой-то алгоритм, который мог бы быть логически оптимизирован, наверняка в одной трех других СУБД он будет оптимизировано.
В текущем виде объект, работающий с БД при запуске программы её открывает и не закрывает, пока прога не выключится. Вроде нареканий нет, но мало ли.
В Postgress тоже
https://www.postgresql.org/docs/current/queries-limit.html
>The rows skipped by an OFFSET clause still have to be computed inside the server; therefore a large OFFSET might be inefficient.
А ты сам то что думаешь, а то виляешь жопой как сеньер блядь на собеседовании.
> В текущем виде объект, работающий с БД при запуске программы её открывает и не закрывает, пока прога не выключится
Это правильно, открывать-закрывать соединения относительно дорого, поэтому их обычно открывают при запуске программы и закрывают при завершении.
>>535732 (Del)
Ну, допустим, а как повлияет на другие параллельные запросы других юзеров и поможет ли мне не дедлокать текущий добавление к текущему
- WITH (NOLOCK)
- WITH (REPEATABLEREAD)
- SET TRANSACTION ISOLATION LEVEL
Хорошим вариантом кажется использование WITH (SNAPSHOT), но оно требует каких-то "таблиц оптимизированных для памяти", как понять такие у меня или нет?
- WITH (NOLOCK)
- WITH (REPEATABLEREAD)
- SET TRANSACTION ISOLATION LEVEL
- WITH (SNAPSHOT)
Если короче, какая область действие будет у вот этого вот?
Там ява и ебнишся сколько драйверов поддерживается.
А насчет рисования схем не уверен. Но ведь тебе и не надо. Ты макакен по перекладываю данных из пустого в порожнее.
>Это правильно, открывать-закрывать соединения относительно дорого,
это пиздежь от ораклистов-онанистов из 90ых.
Тут у чувака SQLLite. Там контекст состоит из примерно ничего.
Может оно и слегка ускорит работу, но, во всяком случае, это не должно быть предметом для беспокойства.
Закрытие БД делает в том числе сбросы кэшей, что может быть довольно продолжительными в случае медленного IO.
да ты заебал.
Если ты задашься целью найти специальный случай, где SQL работает хорошо - ты его найдешь.
SQL вцелом - не говно.
https://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html
Сбросы кешей записи делает завершение транзакции.
Сбросы кешей чтения делает дефицит RAM.
То есть, практически ничего не происходит в SQLLite.
если ты, как полагается, изобразил транзакции, то ничего закрывать не надо.
Безотносительно всяких танцев веб-макак вокруг пула соединений и тд
Даже в SQLite разница на порядок. Сейчас для примера написал два теста с получением 10000 записей в цикле, но в первом тесте соединение открывалось в самом цикле, а во втором перед ним. Разница в скорости в 7 раз. Можно, конечно, рассуждать, что тест не показательный, и на очень специфичном примере разницы никакой не будет, но это всё ещё больший пиздёж, очевидно, что в среднем открывать соединения очень даже дорого.
скажем так:
я имел ввиду, что обычно не имеет большого прикладного смысла нагружать свой мозг и усложнять приложение абстракцией типа "пул соединений"
вот пример от наших латышских (больше не)друзей:
https://support.zabbix.com/browse/ZBX-20450
сделали пул,но забыли что в каждом соединении нужно массу настроек повторить.
>Монга дает тебе из коробки acid транзакции
В твоей ссылке ACID преподносится как какая-то волшебная хуйня для продвинутых пользователей, а не стандартное поведение БД.
>шардинг (которого никогда не будет в постгре или оракле)
Естественно не будет, так как шардинг реализуется забиванием хуя на ACID. А если прикрутить ACID на шарды, то внезапно вся волшебная NoSQL скорость пропадает и остаётся стандартная ёбля на уровне приложения.
>еще множество вещей вроде хранения вложенных структур данных в виде жысона
Жсоны хранить и читать может и постгрес. У вложенных структур есть лимит, после которого их один хуй придётся нормализовывать даже в монге, иначе у тебя кэш обосрётся.
>XHTML
А он был стандартом? XML всегда был перегруженной ебаниной, полной поддержки которой не было ни в одной реализации. Впрочем его душок остался даже в html5 в виде svg (у которого, как и полагается реализации xml, миллион тэгов и разношёрстная их поддержка между браузерами и их версиями). Так что xhtml был мертворожденным продуктом.
А кроме ботов тут никого нет? Кто-то же засунул мой вопрос в бота. Кто ты? Где ты? Отзовись
Ну вот тебе разве не стандарт
https://www.w3.org/TR/xhtml1/
inb4: всего лишь рекомендация
>W3C publishes Recommendations, which are considered Web standards.
Мечтал раньше вызубрить все эти штандарты от корки до корки чтобы от зубов отскакивало.
Да ну ёпсель, неужели тут никто не знает, как повлияют на другие запросы, содержащиеся в текущем запросе хинты таблицы, хинты запроса и вот это SET TRANSACTION ISOLATION LEVEL?
Да ну ёпсель, неужели тут никто не знает, как повлияют на другие запросы, содержащиеся в текущем запросе хинты таблицы, хинты запроса и вот это SET TRANSACTION ISOLATION LEVEL?
Есть задание:
Тг бот для чата многоквартирного дома, которому соседи будут писать инфу о себе( телефон, номер квартиры).
Сам бот уже написан, нужно прикрутить бд куда будет вся инфа о соседях заноситься. С БД у меня опыт нулевой, нужно простейшее решение для этой задачи.
Вначале были мысли использовать монгобд и там же хранить бд, но потом увидел что если из РФ, то иди нахуй.
Какой выход? разбирать postgre и деплоить на обычный хостинг?
>Которому соседи будут писать инфу о себе( телефон, номер квартиры).
Да не будем мы писать в твой подментованный бот. Ты ебнулся?
вот кстати да, на этапе разработки у меня возникли мысли, а не подпадает ли эта хуйня под защиту информации о персональных данных.
мне то похуй, я напишу бота и отдам.
благодарю сейчас гляну
Gavin Powell — «Beginning Database Design»
Ralph Kimball, Joe Caserta — «The DWH ETL Toolkit»
Ralph Kimball, Margy Ross — «The Data Warehouse Toolkit»
W.H. Inmon — «Building the Data Warehouse»
Будет ошибка и констреинт не добавится.
Как прокачаться
Суть - есть таблица ссылающиеся на себя
Как пример
Post
- id
- parent_id
- text
Нужно посчитать количество children у записи
name 2
name 0
Там кое что-то еще нужно в джойнить, но убрал этот момент. Памахите
вроде понял, но чтот тяжело
это в одну группировку делается
select t1.name,count(*) from table t1 join table t1 on t1.id=t2.parent_id group by t1.name
Давно не сталкивался с РСУБД. Есть какие-нибудь хорошие книги/тренажеры/видео на ютубе, где можно подтянуть теорию и практику за месяц-другой? Сейчас вижу, что везде требуют постгрес, а я только с монгой работал на уровне - "ну там документы можно хранить". Сейчас валюсь на базовых вещах вроде уровней изоляции транзакций, например.
>Сейчас валюсь на базовых вещах вроде уровней изоляции транзакций, например.
Это нихуя не базовая вещь.
Видимо базовая, раз ее спрашивают буквально на каждом собеседовании. Я раньше вообще об этом не задумывался. Но буквально на каждом собесе спрашивают "а вот когда какой уровень изоляции выбирать? а в каких случаях? а если две параллельные записи идут? а на чтение какую выбрать?". И это вершина айсберга.
Индустрия карго-культистов, хуле. Еще про говно-солид любят спрашивать, хотя любому с хотя бы одной извилиной очевидно что это хуита ни к чему не применимая ни на практике ни в теории.
Почему?
Самое забавное, что ChatGPT просто не может послать нахуй с некорректным вопросом. Как вообще фреймворк для python может заменить язык запросов в БД?
тупой вопрос тупого говна называющего себя аналитиком.
Что ты вообще имел ввиду?
Можешь ли ты пропустить изучение SQL и продолжать выполнять рабочие задачи аналитика? Зависит от ситуации, но скорее нет.
Сопоставимы ли pandas и sql по "мощности" операций?
pandas - мощнее.
Машина будет говорить все то, что думает большинство.
Доверяя машине ты почти никогда не будешь иметь знать нечто малопопулярное, но популярное в будущем.
То есть, не сможешь стать сказочно богатым.
А я однажды смогу.
Ты - недостоин нейросети.
Триггер. Но нахуй так делать в БД, воткни проверку на уровне логики приложения.
bump
Нужно разделять уровень презентации (dto) и уровень хранения сущностей. А так у тебя выходит, что ты из базы уже достаешь сущность, которую тут же можно вернуть клиенту.
Да. Хочу доставать сразу готовое, потому что трудозатрат смаппить в миграциях во вьюху будет меньше, чем маппить в сервисе.
>максимальное количество одновременных событий за час или день
Это ты сам задание придумал? Потому что "за час" это обычно с 6 до 7, а не с 13:34 до 14:34. "За день" тем более.
И что по твоему если все события начались и закончились строго в течении часа будет проще?
Получается что нет, единственный вариант вижу когда все события начинаются и заканчиваются одновременно, тогда через групировку по времени можно на изи. Ну это совсем хуйня далекая от задачи
>Получается что нет
Почему нет? В твоей схеме ты планировал
>запрашивать через каждую секунду
то есть 86400 раз в день, для разделения по часам тебе нужно будет только 24 раза запросить, что в 3600 раз меньше работы.
Ясно, ты вообще не понял задачу. Ну ладно, хоть тред побампаем, может кто умный прийдет
>Ясно, ты вообще не понял задачу.
Расскажи тогда, в чём отличие от обычной задачи на разбиение по часам, кроме того, что события могут одновременно в нескольких часах быть?
Ты как-то неудачно сформулировал.
Нужен акцент на то что это задача на running total.
В общем, делаешь:
Select max ..
(Select sum(v), point from
(
select 1 as v, starttime as point from ..
union
select -1 as v, stoptime as point from ...
)
...изучаешь как писать running sum with windows functions ..
А хотя нет, сложных window function не нужно.
Просто сумма с предыдущим делается как LAG(v,1) OVER(ORDER BY point)
даст мгновенную сумму
А я с такими объёмами дела до этого не имел (редко, когда в таблице было больше миллиона строк) и не представляю, что вообще может пригодиться.
Мне уже нужно думать о партиционировании?
Какое вообще количество данных в таблице считается разумным?
Во что я могу упереться?
И так далее.
Чего на эту тему можно поизучать? У меня постгря, если что.
Пока что я обвесил базу метриками, убедился, что все запросы происходят по индексам, нет sequence scan и долгих запросов в рантайме запроса. Ну и мастер-слейв организовал, но это давно и заранее.
Какой-то хуевый совет. Зачем удалять? Просто так? Эта хуйня не совсем лежит мертвым грузом, где-то саппорт заходит в старые заказы по каким-нибудь жалобам и/или обращениям, где-то статистика считается.
Да и нахуя вообще удалять, некоторые судя по статьям в интернете, в одной таблице десятки миллионов строк хранят и нормально.
А даже если и удалять, потом ведь может понадобится, надо где-то складировать, предусматривать де-архивацию старых данных.
Сейчас подумал, что можно положить старые данные в отдельную таблицу `_old` и там они могут лежать вечно. Хранение данных стоит копейки, читать и писать туда особо никто не будет, так что держать там можно хоть миллиарды записей (вроде ограничений на число строк же нет?).
А в случае необходимости данные будут под рукой.
Ну я же вижу что ты задаешь вопросы не того уровня чтобы работать с данными.
Вот тебе мысль на подумать:
> Средняя сложность поиска в бинарном дереве - O(log n)
По мере роста размера ничего особо сильно не меняется.
>Какое вообще количество данных в таблице считается разумным?
У всех разные возможности и интеллектуальные и финансовые.
Так что это не должно быть для тебя метрической величиной.
Мне как раз и нужно понимание, на что ориентироваться.
Причём тут сложность поиска в бинарном дереве непонятно, данные не только читаются. Их ещё удаляют (а значит проблема с вакуумом и мусором), реструктурируют, им создают новые индексы (очевидно больно в случае больших таблиц) и всё такое.
Ты пока дал тупой совет "просто удаляй", при том, что вопрос был "как с большим количеством данных живут люди и мне понять, как жить с ними мне?".
Удаление - это одна из опций, которая не является универсальным решением проблем.
Если бы ты был моим крепостным крестьянином и вырос по моим присмотром, я бы тебе ответил что делать.
Кстати, всю твою зарплату я бы тоже забирал.
А пока делай что хочешь со своими решениями. Но вопросы задавай в форме общественно-полезной дискуссии.
Можно обсуждать как выгодно поступить в той или иной обобщенной ситуации. А про тебя мы ничего не знаем. Никакого решения за тебя принять не можем и не хотим.
Изначальный вопрос был
> Чего на эту тему можно поизучать? У меня постгря, если что.
Ожидаемые ответы - рефы на книги, статьи и видосы с конференций.
Но я уже понял, что от тебя вразумительных ответов можно не ждать.
Не так.
Вот твой вопрос:
>Какое вообще количество данных в таблице считается разумным?
То есть, как ы сраном тиктоке решил спросить у подпищеков какую-то хуйню, которая первой пришла в голову. Реально ожидая, что ответят "200 гб - это дохуя"?
И да, мне все равно что будет конкретно с тобой. В этом плаге дискуссия бесполезна для тебя.
Но я готов дискутировать о подходах.
Вот есть у тебя метрики.
Ты сравнивал различия их при условно 2 миллионах строк и при 10? Увидел какую-то просадку?
Принтеры.
Каждый день отсылают данные мол я работаю.
Мне нужен запрос который покажет сколько принтеров за 10 дней отказалось работать.
days , count
1- 2
2- 4
3- 5
...
10 12
http://sqlfiddle.com/#!17/f6f911/2/0
Postgres v.11.9
CREATE TABLE printers (
id SERIAL PRIMARY KEY,
last_working_day DATE
);
INSERT INTO printers(id,last_working_day)
VALUES
(1,'2023-01-01'),
(2,'2023-01-01'),
(3,'2023-01-02'),
(4,'2023-01-02'),
(5,'2023-01-03'),
(6,'2023-01-04'),
(7,'2023-01-05'),
(8,'2023-01-06'),
(9,'2023-01-07'),
(10,'2023-01-07'),
(11,'2023-01-07'),
(12,'2023-01-07');
Этот запрос группирует по дням за 10 дней,совсем не то что надо.
А нужный не могу сделать,не хватает IQ.
SELECT last_working_day, count(*)
FROM printers
WHERE last_working_day > current_date - INTERVAL '10 day'
GROUP BY last_working_day
ORDER BY last_working_day DESC;
Принтеры.
Каждый день отсылают данные мол я работаю.
Мне нужен запрос который покажет сколько принтеров за 10 дней отказалось работать.
days , count
1- 2
2- 4
3- 5
...
10 12
http://sqlfiddle.com/#!17/f6f911/2/0
Postgres v.11.9
CREATE TABLE printers (
id SERIAL PRIMARY KEY,
last_working_day DATE
);
INSERT INTO printers(id,last_working_day)
VALUES
(1,'2023-01-01'),
(2,'2023-01-01'),
(3,'2023-01-02'),
(4,'2023-01-02'),
(5,'2023-01-03'),
(6,'2023-01-04'),
(7,'2023-01-05'),
(8,'2023-01-06'),
(9,'2023-01-07'),
(10,'2023-01-07'),
(11,'2023-01-07'),
(12,'2023-01-07');
Этот запрос группирует по дням за 10 дней,совсем не то что надо.
А нужный не могу сделать,не хватает IQ.
SELECT last_working_day, count(*)
FROM printers
WHERE last_working_day > current_date - INTERVAL '10 day'
GROUP BY last_working_day
ORDER BY last_working_day DESC;
Результат 12.
Такой же ответ как и тут.
SELECT count(*)
FROM printers
WHERE last_working_day > current_date - INTERVAL '10 day';
А требуется ответ
в котором за каждый день сколько принтеров отвалилось.
1 запрос 1 ответ.
Ты не sqlite скачал, а какую-то неиспользуемую никем говностудию для sqlite.
Забыл сказать, что мне нужно t-sql
sql fiddle
Вот так https://hub.docker.com/_/microsoft-mssql-server
Конечно, если ты не знаешь почему Docker, тебе придется помучаться. Но потраченное время с лихвой окупится.
Это он на шинде поставит виртуалку с докером, а в докере нативный для шинды мсскл?
А ты знаешь толк.
Все правильно. А зачем ему виндовый mssql ?
Это же Microsoft. Обещали что все работает - все и будет работать.
У каждого пользователя есть колоды, в каждой колоде есть карты, у карты 2 стороны, каждая сторона может иметь кастомное число строк + всякие медиаданные.
Как такое вообще хранить в базе данных, есть ли у них одна огромная база данных для всех пользователей или она у каждого пользователя своя? В конце-концов они выделяют под юзера ограниченное число памяти.
У каждого своя. Sqlite создаёт один файл, который хранится у самого пользователя, там просто несколько таблиц, с ними делаются обычные селекты-инсерты-апдейты. Никакой магии тут нет, всё просто. Вот одно из описаний схемы БД Anki: https://gist.github.com/sartak/3921255
А, ну со структурой базы данных я разобрался, я реально думал там что-то сложное, а там просто все, уникальное количество строк они хранят в текстовом поле и используют сепаратор.
Но у них есть и вебверсия, мне интересно, каждый юзер имеет свою базу данных там тоже?
Что посоветуете читать по теоретическим основам баз данных, с некоторой практической частью?
Говно на уровне джойнов, оконных функций, подзапросов я умею, но не хватает фундаментальных знаний, чтобы писать эффективный код.
В догонку: или вот на соьесе у меня спрашивают что такое b-tree, а я об этом в первый раз слышу)) в общем мне сильно не хватает фундамента по устройству БД
Как быстрее всего повторить теорию по базам данных и SQL, чтобы не валится на собеседовании на задачках по SQL и вопросам вроде уровней изоляции транзакций и т.д?
Тебе вася нихватает умения бросать мусорные вакансии в чёрный список. Пока тебе только и остаётся, что по разным помойкам шароёбицца, где у тя спрашивают что такое b-tree.
У меня на разраба спрашивали отличие и примеры OLTP и OLAP баз данных, уровни изоляции транзакций и когда какой уровень применять, про виды индексов спрашивали и как они устроены и когда какой применять.
Нет. Ну и про чтение плана запроса или глубокое понимание как оптимизировать запросы тоже спрашивали.
И ты не ушёл.
Глубокое понимание плана это как? Хватит сказать, что надо прочитать используются ли индексы и убрать по возможности сек сканы, правильной расстановкой индексов?
Ньюфаг, да.
Какое место он экономит? При ссылках из других таблиц приходится добавлять несколько лишних столбцов вместо одного айдишника, приходится везде городить compound index-ы, в джойнах нужно писать очень сложные условия, при изменении ключевого атрибута приходится апдейтить все связанные таблицы с риском что-то забыть, в коде приходится вместо одного числа таскать структуру из нескольких полей. Сплошная боль. Используется только в дополнении в айдишникам и обычно только на уровне бизнес-логики.
Звучит резонно, спасибо.
>Какое место он экономит?
Известно какое - не нужен уникальный ключ, если так или иначе ты собираешься объявлять уникальность комбинации двух столбцов.
Короче, нужен - используй.
Не нужен - не используй.
Заебали зумерские вопросы. Как будто вам думать и экспериментировать запрещают и обязательно нужно сделать как у соседа
SELECT
l.Id,
(lc.Content IS NOT NULL) AS ContainsContent
FROM
Logs AS l LEFT JOIN LogsContent AS lc ON l.ContentId = lc.Id
Как правильно запихнуть выражение в SELECT?
А, всё, заебок, сам всю хуйню допёр, ёпта
если у меня есть таблица baza и у нее есть поле foo_datetime timestamp with time zone.
У каждой записи по итогу (после некой обработки) foo_datetime выставляется в null.
Я хочу навесить индекс на foo_datetime, но не хочу чтобы он бесконечно разрастался (тк таблица растет условно бесконечно)
CREATE INDEX baza_foo_datetime_btree_index
ON baza (foo_datetime)
WHERE foo_datetime IS NOT NULL;
так будет работать индекс?
если я делаю запросы типа
SELECT FROM baza WHERE foo_datetime < now()
или могу сделать
SELECT FROM baza WHERE foo_datetime IS NOT NULL AND foo_datetime < now()
как лучше?
оптимизатор - это настолько сложная тема, что проще забить похожими данными и попробовать.
вангую что create index where not null должен работать как задумано.
"дата-аналитик" это 12 тысяч разных работ, и то чем ты занимаешься сильно зависит от конкретной конторы. Я работал в одной и был аналитиком, и код там был только на VBA, ни про какой питон никто и думать не думал, а о БД и подавно. Сейчас работаю во второй и тоже знать языки запросов особо не приходится - одни Панды. Данные выкачиваем из внутреннего портала или апишника, квери пишем джейсонами (и то, чаще копируем и вставляем). Но при этом мой же бывший одногруппник будучи датааналитиком никогда не видел Питон, зато живет в MS SQL Server годами и не умеет ничего еще.
Если ты СОИСКИВАЕШЬ работу, то я бы изучил хотя бы основу скуля, на больше позиций сможешь претендовать.Если тебе комфортно там где есть... тоже изучить лучше, но не критично.
В общем, если найдутся добрые люди, которые готовы решить несколько задач по этим темам за золотую монету, напишите мне в телеге - @nekochan351. Отблагодарю через СБП!!
Всю жизнь работал на MsSql, а тут срочно потребовалось кое что для Оракла делать.. Вроде и тоже самое, но и есть нюансы.
Короче в чём суть. На sql достаточно просто написать запрос, где условно можно создать табличную переменную, присвоить ей результат запроса, а потом из неё, другим запросом, выдать результат. Как то в Оракле такое реализуемо? Можете примерный код накидать?
Ну или, возможно, ты не в курсе что есть CURSOR, который вроде сравнительно стандартизирован ?
Автор имеет ID, а таблица book на него ссылается. Значит стрелка должна идти от таблицы book, разве нет?
Посоветуйте книгу или иной ресурс, где подробно рассматривают как устроен пессимистичные и оптимистичные блокировки в СУБД и как это ложиться на уровни изоляции транзакций. Искал в документации по постгрес, но там есть какие собственные явные локи и про pessimistic/optimistic locking по сути ничего нет... Уже на четвертом собесе попускают...
Виктор Дольник, «Непослушное дитя биосферы».
Роберт Саттон, «Не работайте с мудаками».
Павел Кучер, «Деревянный хлеб».
Конрад Лоренц, «Агрессия».
и т.д. много их!
да этого никто не знает. Никто!
ты кстати можешь просто пропускать собесы где MS SQL упомянут и тогда не нужно будет разбираться в этом
Это почему?. Уровни изоляции ни кто на практике не меняет, а блокировок LOCK FOR UPDATE LOCK FOR SHARE или просто
UPDATE account SET amount = 100 WHERE id=1 AND updated_at='2023-01-24 18:10:15' используют даже пыхомакаки на mysql
Потому, что пропускать надо 90% вакансий, вот почему.
дополню условие. Если беговых еще много, а повседневных осталось мало(например 5), то нужно получить 5 повседневных и 35 беговых
потому что в postresql, oracle и mysql использется так называемая МНОГОВЕРСИОННОСТЬ и вопрос не имеет смысла
тебе тимлид скобки запрещает использовать в SQL или что?
не понимаю сути вопроса.
Надо - делай.
А человека, в точности с такой проблемой как у тебя и сделающего за тебя твою работу, ты редко когда найдешь
откуда мне знать? я знаю только что MSSQL родила концепцию блокировочников, которую все скорее игнорируют.
хотя у тебя в задаче offset пагинация не имеет смысла: ты либо все повседневные перебираешь либо беговые. Тебе нужна keyset пагинация по двум id
последнее выбранное id беговых
последнее выбранное id повседневных
джоинишь таблицу саму на себя декартовым произведением
и выбираешь первые двадцать пар, потом вторые
как-то так
> блок рекомендательный кроссовок на каждой странице магазина
>джоинишь таблицу саму на себя декартовым произведением
> жидко пукнув сервер умирает
на самом деле, мы поняли этот вопрос.
Это непросто. И кроме того, в будущем рекомендацию возможно придется часто менять по прихоти маркетологов.
Сейчас есть даже кооперативные системы рекомендаций и даже мелкий магазинчик способен выдавать рекомендации уровня Алиэкспресса. Но там денег стоит. И все данные придется сливать.
поч он должен умереть?
джоин двух субквери
select * from (select id, name, price from products where type=1 and id > id1) a, (select id, name, price from products where type=2 and id > id2) b limit 20
Да я в целом призываю внимательно относиться с самоджоину, потому как данные быстро размножаются и при неудачном совпадении условий,
сервер может делать много ненужной работы.
Я не вижу тут у тебя limit 20 по какому order by?
На основании чего сервер должен остановиться при выборе type1 ?
Зависит от конкретных данных и движка, но возможна ситуация когда будет дрючить очень много.
Лол пчел и правильно что попустили. Ты там нормальные форму тоже только для постгреса ищешь?
А в постргесе нет пессимистичной блокировки?
Есть таблица postgres, в ней 100к+ записей, столбцов куча, но меня пара столбцов интересует, время последнего изменения и название. Так вот в результате обсера, в таблицу добавили 1к записей, с пустыми название, и образовались дубликаты уже имеющихся данных, у которых все идентично, кроме пустого имени. У них полностью совпадает время последнего изменения, вот поэтому полю я и нашел их. И получается что при выборе, в по автоматом подтягивает последние данные, а там пустота в имени. Задача стоит их найти и удалить только те где название пусто
Каким образом?
Having group by подзапросы это все на1% понятно в теории, на деле, ищется всякая хуета, нашел только пустые имена, но время как сравнить чтобы их удалить? нашел дубликаты по времени, но куда еще че вписать чтобы их ид вытянуть иначе как удалять? толку от того что знаю что их тысяча если некоторые даты повторяются для совсем разных строк более 2 раз. Чем дальше сидел пыхтел тем больше запутался и нихуя не вдупляю
>У них полностью совпадает время последнего изменения, вот поэтому полю я и нашел их
up нашел не так, а нашел тупо по пустому названию, строки, но есть строки пустые которые должны быть и они были до обсера, поэтому удалить надо только те что добавили недавно, у которых время совпадает, за последнюю неделю
Изучаю sql неделю, решаю задачки и совсем не могу понять один момент в конкретной задаче:
https://www.sql-ex.ru/learn_exercises.php
32 задача.
Задача решает вот таким кодом:
SELECT
country,
CAST(AVG((boreborebore)/2) AS NUMERIC(6,2)) AS weight
FROM
(select
c.country,
c.bore,
s.name
from
Classes as c
inner join
Ships as s
on
c.class = s.class
union
select
c.country,
c.bore,
o.ship
from
Classes as c
inner join
Outcomes as o
on
c.class = o.ship) AS t1
GROUP BY
country
Но я не могу понять почему, если убрать в обоих подзапросах s.name и o.ship соответственно, то некорректно считают корабли из USA и Japan?
Изучаю sql неделю, решаю задачки и совсем не могу понять один момент в конкретной задаче:
https://www.sql-ex.ru/learn_exercises.php
32 задача.
Задача решает вот таким кодом:
SELECT
country,
CAST(AVG((boreborebore)/2) AS NUMERIC(6,2)) AS weight
FROM
(select
c.country,
c.bore,
s.name
from
Classes as c
inner join
Ships as s
on
c.class = s.class
union
select
c.country,
c.bore,
o.ship
from
Classes as c
inner join
Outcomes as o
on
c.class = o.ship) AS t1
GROUP BY
country
Но я не могу понять почему, если убрать в обоих подзапросах s.name и o.ship соответственно, то некорректно считают корабли из USA и Japan?
Капец код потек.
С UNION ALL начинает корректно считать Японию, но USA все равно считает неправильно.
С UNION ALL начинает корректно считать Японию, но USA все равно считает неправильно.
Как правильно хранить историю версий объекта в sql таблице?
Допустим я храню ветку форума из постов, с полями [post_id, thread_id, timestamp, message_content]
Периодически message_content может меняться, я хочу хранить историю изменений.
Есть ли какой-то элегантный способ хранить её прям в той же таблице? При том что post_id это pk и его не хотелось бы менять.
Соответственно, запросов к предыдущим версиям объектов мало, чтений актуальной версии много.
> Как правильно хранить историю версий объекта в sql таблице?
Чаще всего тупо делают отдельную таблицу с историей, с таймштампами, без внешних ключей, без NOT NULL, UNIQUE и других констреинтов. Ещё есть подход Data Vault.
> Есть ли какой-то элегантный способ хранить её прям в той же таблице?
Зачем? Можно, конечно, сохранять старые версии постов как фиктивные посты с другим номером и с отдельным столбцом-ссылкой на актуальный пост, для настоящих постов там будет NULL. Но придётся в каждом селекте проверять этот столбец на NULL, чтобы отсечь исторические записи, также придётся быть осторожным с внешними ключами, да и индексы будут занимать больше места (хотя это вряд ли критично).
>Зачем?
Просто если хранить историю в отдельной таблице то нужно при обновлении версии отдельно писать в неё (кстати, можно ли это делать средствами самой субд при апдейте?), а ещё нужно руками держать схемы двух таблиц в соответствии.
В одной таблице хочется для того чтобы это было бесплатно с логической точки зрения, типа есть основная таблица где все версии свалены в кучу, а есть вьюха из которой можно читать актуальные версии, типа того.
> можно ли это делать средствами самой субд при апдейте?
Можно устроить помойку в триггерах, но не стоит так делать. В базе данных должны быть данные, а не логика.
пчел, CDC
Создаю схему бд для книг, там есть серийный номер книги, получается, что можно серийный номер посчитать как id?
Или серийный номер может совпадать?
если ты про ISBN, разумеется, он никогда совпадать не может
Ссылка на бд и задание
http://sqlfiddle.com/#!4/c6dcc
Сорян, задание не отобразилось
1)Выберите наибольшую сумму заказа для каждого продавца за последний год. Вывести: имя продавца, имя заказчика, месяц заказа, сумму заказа.
GROUP BY и MAX().
Как теперь этот файл просто посмотреть? Без поднятия настоящей СУБД никак? Хорошо, как для MariaDB это сделать быстро (у меня пока не прод)?
P.S. База ни разу не purge'лась, это достоверный факт. Уверен, что не"удалённой" инфы там метров под 300 максимум.
Нет.
pg - нужно получить количество уникальных сочетаний 2 колонок. У меня получились такие варианты:
1)
SELECT COUNT(*) FROM (
SELECT DISTINCT customer_id, ship_country
FROM orders
) q;
2)
SELECT COUNT(DISTINCT concat(customer_id, ship_country)) FROM orders;
3)
SELECT COUNT(DISTINCT customer_id || ship_country) from orders;
Остался вопрос - а какой из них лучше/правильней?
Смотри планы запросов через EXPLAIN ANALYSE. Если нет composite индека на обе колонки, создай.
Юзай что хочешь. Думаешь, нам не похуй?
Это тебя взгреет твой куратор, дорогой начинающий датасаентист. И без премии оставит. Не ты выбираешь СУБД, а СУБД выбирает тебя.
SQL строится на теории множеств, а у элементов множества не определен порядок. Поэтому дwindow functions появились сравнительно поздно.
Между прочим, в pandas тебе придется все загрузить в ОЗУ.
https://stackoverflow.com/questions/4031484/how-to-purge-the-database-data-and-log-files-in-mysql
https://stackoverflow.com/questions/2646373/mysql-data-file-wont-shrink
SUKA BLYAT https://www.youtube.com/watch?v=B8Fi5innpsg , тогда какого хуя этим говном вообще пользуются, если за этой Марией ДолБоёбовной в принципе невозможно почистить? Остались ли вообще ещё какие-то нежрущие, но масштабируемые СукБД?
честно говоря никогда не понимал зачем кто-то пользуется mysql когда есть и всегда был postgres, который лучше нее буквально во всём. ладно бы он был платный или заточен только под какую-нибудь странную ось типа фрибсд, или сложен и дик в настройке и обслуживании, но нет же, он бесплатен и прекрасно устанавлоивается и работает везде, и без этих ебучих недокостылей которые в мускле всю дорогу. по каким таким причинам mysql вообще жив для меня загадка вот уже 20 лет как.
Order by length(regexp_replace(lower(yourcolumn), '[^aeiouyаэиоюуеёюя]', '', 'g'))
Но это твомедленный и тупой способ.
- в mysql появилась репликация. раньше чем в postgres.
- в mysql есть query cache, которого никогда не будет в других субд
- проект может быть корнями из веба или порождением веб-программистов
- mysql как часть дистрибутива чтобы было полегше.
>Есть дамп MariaDB (текстовый файл с расширением sql)
>если за этой Марией ДолБоёбовной в принципе невозможно почистить?
ты осознаешь, что база в sql содержит ровно те данные, которые туда положили и НИКАКИХ СОВСЕМ НИКАКИХ данных обусловленных накладными расходами или внутренними потребностями mysql?
То есть, гуглишь какую-то хуйню и бомбишь без повода, только из-за плохого понимания СУБД вообще
> - в mysql появилась репликация. раньше чем в postgres.
ну это же ложь. я не знаю как сейчас, но в мускле нормальной репликации не было никогда, даже в тот момент когда ее оракл купил. в постгресе же репликация всевозможных видов была еще 20 лет назад
> - в mysql есть query cache, которого никогда не будет в других субд
опять ж ерунда, querycache в постгресе есть уже без малого 15 лет как
> - проект может быть корнями из веба или порождением веб-программистов
и как это связано с выбором мускля в качесте СУБД?
> - mysql как часть дистрибутива чтобы было полегше.
насчет "полегче" я сомневаюсь что мускл лучше постгреса в этом отношении.
Тогда ещё более тупой способ:
Order by (length(yourcolumn) - length(replace(replace(replace(..., 'i', ''), 'e', ''), a'', ''))) - вложенных реплейсов столько, сколько гласных.
Ну либо писать хранимую функцию, которая посимвольно обойдёт строку и вернёт количество гласных.
Делаешь подзапрос, который вернёт два столбца - id и кол-во гласных, с помощью него выводишь из основной таблицы данные через order by
Вопрос по graphql. делаю запросы к api.github.com - всякие фильтры для запросов тестирую.
Хочу выложить свой проект в репозиторий для портфолио, но само собой не хочу держать в репер свой токен от гитхаба.
Могу ли я для незарегистрированного, по сути локального, приложения прикрутить oAuth гитхаба? не могу найти пока ничего годного, кроме как сделать инпут текста, куда пользователь будет вручную вводить свой токен.
Спасибо
кто здесь кто? Почему именно эти животные на логотипе программы Dbeaver ?
Вероятно тот самый бобёр, отсосат гитхабовский и слон в качестве постгреса? Почему так, спрашывай у упоротых десигнеров.
Да хоть бы дельфинчик mysql...
Вот как ты такую хуйню замечаешь? Сколько ни юзал - узнал о животных только после твоего поста.
Хорошая мысль! А то я как-то изгалялся с вложенными запросами и SELECT (conditions_sum) AS myrank, чтобы потом можно было ORDER BY myrank, потому что в 1 выборке не получалось... А так в 2 раза короче. И секция WHERE освобождается. )
Вынеси в подзапрос.
select ⚹ from (
select ⚹, column1⚹50 + column2+4 as tempresult
) order by tempresult
Но ведь может быть. Пишу простенький дб админ в качестве пета. Вот бумаю в таких случаях предупреждать и удалять все нах что совпадает по столбцам.
В оракле есть ROWID, который стопудово будет в любой таблице уникальным, даже если значения всех полей совпадают. Вот по нему удобные инструменты и работают. Не знаю, есть ли подобное в постгресе.
Наверно у всех бд есть скрытый rowid или cid, но проблема в том
что сможешь ли сделать
DELETE FROM some_table WHERE rowid = 1;
Сможешь.
Просто есть ограничения по времени и поэтому думаю, стоит ли отвлекаться и углубляться в эту тему или просто пока продолжать использовать орм
часа два достаточно
> зачем создавать второй алиас на ту же таблицу?
Это self join, из одной и той же таблицы делаются две выборки, и каждой записи из первой выборки ставятся в соответствие ВСЕ записи из второй выборки. Получаются все возможные комбинации записей из первой и второй выборки (декартово произведение), например, если в таблице 3 записи, в итоге будет 9 записей. Дальше применяется where, чтобы отфильтровать результат.
> почему мы декларируем столбцы в а. таблице, но не делаем этого в таблице b.?
Это не декларирование, а просто список значений, которые надо вернуть в результате запроса, чтобы не возвращать все столбцы. В самом запросе можно использовать все столбцы из всех таблиц, из которых производится выборка.
бтв есть ли какая-то тулза, которая бы автоматически ставила пробелы для выравнивания селекта по AS?
> мне одному хочется пиздить палкой тех, кто используется синтаксис запятой вместо явного CROSS JOIN?
Не одному. Я никогда не пользовался джойнами, всегда писал селекты из десятка таблиц через запятую, потому что мне похуй, потому что могу.
Псину свою палкой пизди.
Да ни в чем, только вопрос предпочтения и удобстве чтения кода
Есть такая тема как SCD паттерн.
Можно реализовать по-разному. На практике приходилось юзать такой подход: в таблицу добавляются доп поля - id, active_from, active_to (таймпстампы), is_active (bool). id - это id записи. post_id - это id сущности. Соответственно когда ты в первый раз добавляешь запись с каким-то post_id, она становится единственной активной записью с этим post_id. Когда ее "изменяешь" - в первую запись проставляется текущая active_to и снимается галочка с is_active. И добавляется новая запись с тем же post_id, но с другим id и с галочкой is_active = true и соответственно с другими данными в полях. Таким образом у тебя всегда одна актуальная (активная) запись под каким-то post_id, и ты так же можешь посмотреть все изменения. Норм тема, но там возникает ебля с уникальностью и со связями, поэтому fk вряд ли нормально удастся навесить.
> Это не декларирование, а просто список значений, которые надо вернуть в результате запроса, чтобы не возвращать все столбцы.
Не уверен, что правильно тебя понимаю. На скрине окно которое показывает правильный ответ. Почему в нем есть a.First_Name a.Last_Name, но нету b.First_Name b.Last_Name ?
То есть, представим, что существует таблица с именем tables, в которой хранятся имена других таблиц (table_1, table_..., table_n) и их ID (1, ..., n). В этих других таблицах - не важно, что содержится.
Мне нужно получить содержимое таблицы с ID 1, не зная имени этой таблицы.
Я могу это сделать в два действия:
сделать сначала
select name from tables where ID = 1
, посмотреть название таблицы с ID = 1 и затем сделать
select from table_1
А можно ли это выполнить в одном запросе? Что-то вроде:
select from (select name from tables where ID = 1) (это выглядит как запрос из подзапроса, но мне нужно не это. Мне нужно использовать полученное значение именно в качестве имени (части имени) таблицы/БД).
UPD: речь про MSSQL
Да, через dynamic SQL.
Делай в два и не выебывайся, вменяемого решения нет.
А вдруг он пишет свою платформу наподобие 1С с велосипедным словарём данных, где можно налету создавать таблицы мышкой в конфигураторе.
>ты осознаешь, что база в sql содержит ровно те данные, которые туда положили и НИКАКИХ СОВСЕМ НИКАКИХ данных обусловленных накладными расходами или внутренними потребностями mysql?
А её рабочий вариант в InnoDB - содержит, и аналога VACUUM из PostgreSQL там нет. И вообще из популярных SQL-движков без костылей такое только в PostgreSQL и SQLite нашлось.
>То есть, гуглишь какую-то хуйню и бомбишь без повода, только из-за плохого понимания СУБД вообще
Да просто на работе OpenNebula юзают, а там и в актуальной-то постгре(с) в альфе, а в нашем говне мамонта только МарияДолБоёбовна и SQLite. Хоть бери и ЁбаньЁбалу на клиторе клипере переписывай.
Чё. Где подробности.
Наверняка не закоммитил.
У меня фирма работает на нескольких площадках.
Соответственно есть таблички в экселе вида - код работ, наименование работ, объем, срок и тд.
Я хочу в одном месте иметь доступ к этим табличкам и делать всякие запросы - поиск работ по коду среди разных площадок. И так же добавить пару столбцов, где отмечать сколько % выполнено и когда, чтобы можно было делать запросы типа - выведи все работы сделанные в марте.
Что-нибудь легкое, на пару тысяч строк.
Я просто был тут на заводе и видел как у них есть подобная тема. Там видимо на серваке лежид бд, а они через мозилу туда заходят. Мне было бы удобно, чтобы как гугл драйв это работало, когда на паре компов ставишь синхронизацию и все файлы через одно облако синхронизируются. Так что и локально без интернета можно на любом пк глянуть и при наличии интернета все обновляется. Опционально, чтобы можно было постучаться в бд через браузер(скажем дать человеку пароль и он зайдет посмотрит отчеты).
Ну наверное можно было бы и просто в экселе все в общую таблицу свести, но хочется прям красивую удобную штуку с норм интерфейсом, заточенным под работу с бд.
Тебе ведь не БД/СУБД нужна, а некое приложение, где отображаются различные таблицы а-ля 1С? Внутри оно понятное дело будет использовать какую-нибудь СУБД, но ни один пользователь непосредственно с БД работать не будет, только с некой прослойкой-приложением, которая подключается к БД.
Наверное так и есть. То есть где-то будут валяться таблички с приведенными данными. А мне нужно окошко, где я могу делать запросы и мне красиво все будет выводиться.
То есть я вот видел у челов - в мозиле открывают что-то и там есть поля для ввода и кнопка вывести.
Скажем ввожу - площадка 1 и мне выводит все работы на площадке 1. Ввожу код 2 и мне выводят все работы с кодом 2 со всех площадок. Ввожу площадка 3, код 5 и получаю только эту работу с данной площадки. Это самое базовое, что мне надо. А то в экселе, либо нужно с 10 таблиц сверять, либо если загнать все в одну таблицу, то тоже данные не выводятся в подряд, а скачешь по таблице. Неудобно.
И я хз как это описать, но бонусом было бы здорово иметь вложенность данных. Вот допустим у меня есть поле объем и поле выполнено. И вот в поле выполнено нужно иметь возможность вводить несколько данных. Типа сделал 20%, забил в табличку, там отметилось время. Потом через недельку делал еще 20%, забил в табличку, там отметилось время. То есть не перезаписывать 20 на 40%. А потом можно было бы по вот этому времени делать запрос - работы в марте и там вот выводит, что 20% такой-то работы сделано в марте.
Скорее всего, есть какое-нибудь готовое решение, то ли небольшая ERP, то ли трекер задач наподобие Jira. Здесь вряд ли такое посоветуют, можно поспрашивать в /biz/ или /s/.
Но она уже год в опенСорсе и нет особых упоминаний
https://habr.com/ru/company/yandex/blog/660271/
>ydb
>ультра годнота для высоких нагрузок
А тебе это зачем? Это поделка яшки, которая никому не нужна. Где ты будешь искать ответы на вопросы, когда у тебя в проде начнутся проблемы? Бери постгрес и не выебывайся.
Нет, я хотел сам сделать. Я думал, что уже есть нечто подобное. Ну или может есть какой-нибудь конструктор, где можно полей наформошлепить и потом прописать им пару пару действий. Типа как для сайтов есть такие штуки. Не изучать же С++ ради этого.
Миллион таких конструкторов есть. Если у тебя эксель, то самым ближайшим конструктором является Access
Да и в самом экселе есть возможность встраивать формы
Делаю сервер онлайн дрочильни, нужно реализовать схему инвентаря в бд. Хуй знает как сделать так, чтобы производительность не падала.
Думал сначала так:
1. таблица с игроками
2. таблица со всеми возможными предметами в игре
3. таблица принадлежности конкретного предмета к конкретному игроку
Хуйня же полная, да?
Ясн, аксес я краем глаза видел, выглядит хуево, но вроде то, что надо.
Подскажи, а как вот эта вложенность реализовывается про которую я писал? В моем представлении получается, что ячейка с выполнением работ ведет к таблице, куда заносится процент выполнения и дата. Ну и получается что к каждой строке в таблице будет еще по таблице прилагаться.
> Хуй знает как сделать так, чтобы производительность не падала.
Не использовать реляционные БД, они плохо для такого подходят. В нагруженных онлайн-дрочильнях часто пишут что-то своё, к примеру, держат всё в ОЗУ и раз в несколько минут сохраняют состояние на диск. Это не банковские системы и не мессенджеры, где без ACID-транзакций никак.
Вообще, правильным решением будет не использовать реляционную бд, как и сказал анон выше. Но в общем случае в твоей задаче делают табличку с предметами и ассоциативную табличку со столбцами вида player_id, item_id, items_amount. Сделаешь индекс на player_id, и скорость будет сносная.
Как правильно и безопасно хранить ssh ключ,если мне необходимо хранить его в базе данных?
Приватные ключи выдавать кому-то на хранение вообще небезопасно, их надо хранить на флешке в анусе.
(f'В {file_name} наименоваия файлов не совпадают со списком {path_file}. Список наличия в {path_file} следующий: {result_1}')
Как сделать такое значение в insert sql?
Значение вычисляется на питоне, БД - postgres, тип поля varchar(10000)
Постгре это действительно не Оракл, но все идёт к этому. Пока кредитные конвейеры ссыкуют использовать Постгре, кстати.
Лет 20.
>Сколько по вашему мнению пикрил продержится в РФ?
все зависит от политической обстановки, могут вылететь в одночасье как гугл
>Крупный ритеил и банки юзали ораклу для OLTP
государству на них поебать, а после 2014 использование ораклов и прочих других не опенсорц решений в ящиках свелось к нулю. так что если надо будет выпнут за неделю признав какими-нибудь экстремистами.
>Пока кредитные конвейеры ссыкуют использовать Постгре, кстати
ну в околобанковской теме принцип не трогай если работает охуеть какой мощный. попрой просто накатить патч безопасности - это уже охуеть какой бюрократический квест. так что если административных мер не будет то оракл протянет в рф еще ооочень долго.
Начал читать книжку по PostgreSQL, там нужно импортировать учебную бд, но у меня чёт не получается, пробую по гайду из книги в psql ничего не происходит, пытался просто через cmd, ругается, думаю, что где-то чёт не правильно пишу либо не дописываю, не могу понять где
куда exe ?)
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PostgreSQL15" -U postgres -f demo_small.sql
Может нахуй тебе тот посгрес, а?
>Типа наебали CAP теорему
именно так.
Но дело в том, что она особо никого и не волновала кроме контор уровня Яндекса.
Ты не в том треде спрашиваешь, тебе ближе этот: >>2484578 (OP)
А здесь дрочат сами базы данных независимо от применения.
о, спасибо, анонасик
Почитай про джойны.
В данном случае ты делаешь кросс джойн, то есть все комбинации записей первой таблицы со всеми из второй.
Если их много, то результат будет очень большой и оно обосрется, что видимо и происходит.
есть ли какое-либо общее правило когда следует создавать отдельную таблицу?
Например есть таблица с пользователями, у пользователя может быть статус pro (true / false) и описание к статусу
Понятно что таких пользователей будет не много (4 из 1000) и соответственно хранить это пустое поле у всех кажется лишним.
Это тот случай когда лучше вынести статус в отдельную таблицу?
И вот ещё: где лучше хранить пользовательские роли (admin, moderator, user, etc.), в отдельной таблице или прямо в таблице users?
>>общее правило когда следует создавать отдельную таблицу?
гугли нормальные формы
>>Это тот случай когда лучше вынести статус в отдельную таблицу?
зависит от логики приложения, скорее да чем нет
>>где лучше хранить пользовательские роли
>>в отдельной таблице или прямо в таблице users?
отдельно таблица с ролями
в users только ид роли
часто есть еще таблица permissions с доступами и role_permissions указывающая какая роль какие доступы имеет
Спасибо за наводку, а то в учебниках про это ни слова, только операторы и прочее, в общем база
Сейчас сам нормализуюсь
> отдельно таблица с ролями
в users только ид роли
Почему так? Это же увиличивает время выборки ещё, так у нас в пользовательской модели всё будет, а так придётся подтягивать ещё одну таблицу(цы)
>>Почему так?
1.
роль/полное_название_роли/описание_роли - зачем все это в юзере? Этих полей может не быть сейчас, но появятся позже. А менять такие таблицы со временем все дороже.
2.
Если уверен что роли точно не будут создаваться без изменения кода - можно и просто какой нибудь enum воткнуть в роль (по факту в базе это varchar). string вместо enum не стоит - одна ошибка и ты ошибся, так хоть какой то контроль.
>>так у нас в пользовательской модели всё будет
Роли без пользователя не нужны? Пользователь без роли не нужен? Будешь каждый раз прописывать каждое нужное поле для выборки? Толстые модели тоже имеют свои минусы.
>>увиличивает время выборки
Если у тебя йоба хайлоад там немного другие правила и НФ3 идет лесом, но обычно таких требований нет и париться о таких вещах излишне.
Вот есть задача по SQL List all the cities west of Chicago, ordered from west to east
SELECT * FROM north_american_cities
where longitude <= -87.629798
order by longitude
Я такое решение написал. А можно каким-нибудь оператором, не вбивая ручками долготу -87.629798, написать, типа: "посмотреть у города Чикаго значение долготы" и уже с ним работать?
Через подзапрос.
SELECT * FROM north_american_cities where longitude <= (select longitude from north_american_cities where city_name = 'Chicago') order by longitude
Спасибо.
Ещё вот задание https://sqlbolt.com/lesson/select_queries_with_outer_joins
Find the list of all buildings that have employees
Я его решил так: SELECT distinct Building from employees
Но, подозреваю, что от меня другого хотели с этими джойнами?
Там три подзадачи, решение с дистинктом по employees подходит для первого. Дальше надо вывести ещё инфу по численности и должностям и общему количеству рабочих мест, уже надо делать джойн.
Я просто ковырялся в аксесе и мне, кажется, что вместо тыкания всяких кнопок и хз чего еще, проще было бы просто код написать.
A = B
B = C
A != C
И при этом они должны считаться дубликатами.
Чот не могу придумать
вобщем узнал про рекурсивные запросы. Вроде работает
нужно сделать запрос в БД (pgsql) и если значение, с которым я прихожу, больше значения в БД, нужно обновить запись БД
как это сделать в один запрос, а не два?
спасибо
спасибо
привет, подскажите пож
можно ли как-то объединить запросы
select id from 'table'
where col_1 = 'value1' and col_2 = 'value2' and col_3 = 'value3'
если нашли, то заменить значение одного из полей на другое
если не нашли, то заинсертить
извините, что так бездарно описал
вообще, кажется вот это то, что мне нужно:
INSERT INTO table (id, name, age) VALUES(1, "A", 19) ON DUPLICATE KEY UPDATE
name="A", age=19
только проблема в том, что я заранее не знаю id, но предполагается что комбинация name и age у меня будут уникальными
Айди не нужен тут, он сам подхватится, ну если ты сделал это поле первичным ключом
Ну и name + age уникальным ключом
Это не совсем реляционка а типа "лейкхаус", но у нас на проде крутится delta lake - там как раз поверх Паркетов есть "дельта", т.е. полный транзакционный лог. Потом выше этой хуйни стандартные SQL-запросы можно гонять через Spark API (он дельту нативно поддерживает).
Аноны, подскажите, пожалуйста, как совершить запрос SQL.
Есть таблица (пик), Мне нужно получить строки apple серого цвета. Как можно это сделать? Я же не могу проверить столбец на два значения одновременно.
Хуевый дизайн, это схема many-to-many. Т.е. нужны табилцы на продукты, проперти и связка продукт-пропертя.
Ну это надо как-то через жопу делать, потому что дизайн хуевый.
Надо у гопоты спросить, он там пошуршит по стековерфлов такие дурацкие вопросы.
Такое кажет, вроде норм выглядит, но я не проверял.
SELECT DISTINCT t1.prodct_id
FROM your_table_name t1
JOIN your_table_name t2 ON t1.prodct_id = t2.prodct_id
WHERE t1.code = 'brand' AND t1.value = 'apple'
AND t2.code = 'memory' AND t2.value = '128';
Хотя это должно ебово тормозить где больше полтора строчки, по-моему.
попробуй так
select (product _id) from table where code='color' and value = 'Grey'
INTERSECT
select (product _id) from table where code='brand' and value = 'Apple'
Ну это суть тот же селфджойн.
Есть две таблички. Главная и подчиненная, связанная по внешнему ключу.
Ну и я удалял их каскадно, удаляешь главная, по внешнему ключу удаляются все подчиненные - все хорошо.
А теперь у меня есть задание написать другую апишку, в которой надо не удалять каскадно, а получать ошибку, если есть связанные таблицы.
Можно делать и то и другое на уровне постгреса? Или я обязательно должен в одном из сценариев делать два запроса на уровне приложения ?
неактуальные данные из oltp скидываются в data warehouse
был знакомый разраб который утверждал что за хранение логов в боевой базе нужно пиздить ногами
Что такое "сложные выборки данных"? OLAP?
Альтернатива ручному вбиванию SQL - это и есть ORM, которые генерируют и выполняют SQL сами. Из минусов - надо очень хорошо знать SQL и кишки выбранной ORM, чтобы не выйти на проблемы, которых с голым SQL никогда не бывает.
Что выглядит тупо? Почему sql выглядит тупо? Не пиши здесь хуйню больше
Вот поступает запрос, нужно получить из бд пользователей, товары или что угодно. Допустим запрос сложный и включает несколько подзапросов. Мы прямо харкодим нужный запрос в виде sql, или есть какие-то приёмы/паттерны итд для абстракции таких деталей (кроме ORM)?
ну блин, прямо в программном коде начинается простыня "SELECT XUY FROM PIZDA WHERE ...". Если запрос большой и сложный, его прямо так и оставляют в виде строки, или существуют абстракции которые представляют запрос в ином виде?
Приложение должно так или иначе сформировать SQL и передать его СУБД. Ну какие тут могут быть абстракции? Можешь вынести запрос в файл или другой класс как константную строку, назвать это "Репозиторий" и на уровне логики обращаться к нему, логику дёргать из контроллера. Как код ни организуй, суть не изменится.
Когда говорят «захардкодить», то это означает, что ты в код вставил какую-то константу, например логин или айди, к которым нельзя привязываться и это должно быть параметром конфигурации
Судя же по той дичи, которую ты пишешь, ты почемуто боишься sql-запросов как факта. Да, в концепции orm, подразумевается, что запросы руками не пишут, но это не жесткое требование, orm позволяют и писать вручную, если это необходимо. Ну и конечно же orm это не единственная концепция и код бывает пишут строго на чистом sql, слово “хардкодить” не уместно здесь ни в одном варианте
>>есть какие-то приёмы/паттерны итд для абстракции
Для джавы существуют QueryDSL, jooq например. В других языках наверняка есть аналоги.
Вот я про такую херню примерно и спрашивал, это же просто билдер для обычных sql запросов, и уже смотрится прилично, глаза не вытекают. Как эта хуета называется? Хочу загуглить как в других языках и фреймворках это может выглядеть.
Для каждого типа - свое.
clickhouse - для бигдаты
Neo4j - для связи сущностей, как в соцсетях
Redis - для кешей
Mongo - для фронтодебилов не осиливших sql сущностей с неопределенной структурой типа жсонов
Читай пикрил короче.
Хз как это правильно называется, query builder какой-нибудь.
Хранить логи и конфиги, реализовать кеши и очереди.
query builder тебе правильно подсказали https://youtu.be/x1fCJ7sUXCM?t=770
>уже смотрится прилично, глаза не вытекают
пиздец ты поридж конечно
Например, есть несколько типов расписания - повторяющееся и на конкретную дату. У повторяющегося есть поле "дни недели", а у обычного "дата" (возможно ещё стоит добавить "тип", чтобы их различать).
Мне на ум такие варики пришли:
Хранить в реляционной бд с помощью entity–attribute–value.
Хранить в монгодб.
Хранить в двух разных таблицах.
ладно, я еблан. Отставить
подскажи, как получить номер строки в pgsql без перебора всей таблицы? в таблице +100.000 строк, а оптимизация важнее двача
Что значит найти номер строки? Ты не можешь его найти, потому что формулируешь плохо
как научиться формулировать лучше
но тогда мне вернется вся моя таблица с порядковыми номерами, а мне нужен только порядковый номер одной строки
Тогда номер строки будет равен 1.
интересно отследить момент когда то что раньше называлось кешем начали называть базами данных.
Никогда?
Редис не является кешем сам по себе. Просто за счёт того, что он key-value и in-memory, поверх него часто реализуют кеши. Можно с тем же успехом взять реляционную СУБД, создать там временную таблицу, живущую в ОЗУ, и юзать её как кеш, но ведь никто не говорит, что ораклы/постгресы - это всего лишь кеш, а не СУБД.
разница не в технической реализации, а в методологии.
бд хранит данные, собранные в структуры, а рсубд более того, как модель, которой можно управлять с помощью математической теории множеств, а кеш хранит данные похуй как лишь бы быстро отдавать. поэтому когда у вас в приложении только монга, то у вас БД нет, а есть только кеш, который по недоразумению называется базой данных. с такой то логикой любой мусорный контейнер можно называть архивом временно ненужных вещей, хотя по факту это просто свалка мусора.
Если ты сам для себя решил, что база данных - это то же самое, что реляционная база данных, так тому и быть. Только объективная реальность от этого не изменится.
Гуглил, там все решения для mysql, установленного на хосте, а с калтейнерами ни у кого такой ошибки видимо не возникало. Ну и решения соответственные, проверить брандмауэр, включить службу mysql, сделать бочку и т.д.
Что я делаю не так? Кто сталкивался? Как фиксить?
Причина была прозаична. Виндоус не сразу вкинул окно с разрешением доступа докера к сети. Стоило разрешить, все сразу заработало как надо (ну почти).
С портами все норм, пикрил.
Зашуганное, оттого усердно проецируещее свою работу в макдональдсе на окружающих, омежное чмо >>665280 может попуститься.
мимо >>665152
Вот что это значит (T-SQL):
> 2.1 Создать dbo.SKU (ID identity, Code, Name)
> 2.1.1 Ограничение на уникальность поля Code
> 2.1.2 Поле Code вычисляемое: "s" + ID
Я не понимаю хитрого замысла с 2.1.2 и, как вытекающее, 2.1.1. Зачем UNIQUE если ID is identity/PK, который гарантирует уникальность?
И что понимается под "Поле Code вычисляемое: "s" + ID". Про процедуры ничего не сказано, значит это должно быть на уровне Бд. Ну не ТРИГГЕР же для INSERT писать, сразу ссаными тряпками закидают.
Где хитрость?
Уникальный констреинт автоматически создаёт индекс, и поиск по коду будет практически таким же быстрым, как по ID. Возможно, смысл в этом.
Вычисляемое поле - это computed column. Т.е. без явного написания триггера указываешь при создании таблицы что-то вроде:
Code AS (CONCAT('s', ID)) PERSISTED
>Есть те кто переходят/переходили на PostgreSQL? Работал два года с MsSQL и Oracle.
ну это как если бы ты привык покупать ливайсы на oipolloi и 911 nb, но обнищал и ты идешь и берешь штаны и боты из козжама с дырочками на лето в местном тц
как то так
да вполне четко отслеживается вплоть до года когда начался nosql бум
связано это было конечно с тем как хтмл-макаки переоткрывали мир заново и для них на месте окна в который они полюбили лазать прорубили дверь
>Реальный, конкретный кейс когда это надо, и почему.
если делаешь себе смузи и ходишь в модную кафешку на обед, то надо, если ходишь с тормозком на работу и отдыхаешь от компа на даче - то не надо
тащем та смотришь сгенерированный sql если че не так получилось, хмыкаешь, исправляешь, если не получается, то смотришь план запроса, хмыкаешь, исправляешь
ничего сложного главное не боятся лезть в потроха
ну до эпохи веб-макакинка альтернатива была активные гриды, ты накидывал элемент на формочку, че то там шаманил и у тебя рабочий грид
наверняка сегодня и в вебе есть полно таких конструкторов активных гридов и других активных элементов типа списков там и окошек ввода и прочее
Кэш и сейчас есть, прослойка над PHP и SQL когда делать запрос к SQL не всегда иеет смысл
В 45 на бордах не постят, а живут в загородных домиках и катаются на своей лодке.
Кто тут зумерок, если твоя жизнь что в 18 что в 45 не изменилась, лул
Как будто у тебя изменится. Типичний ойти это тот же петрович, только тот гайки крутит, а тот в стул пердит и кнопки жмет.
https://app.dbdesigner.net/designer
Не рекомендую. Есть ограничение: можно сохранить только тот файл, в котором не больше 10 таблиц. Требует регистрации для этого, обновляет страницу (так что просто оставить открытую вкладку не получится) - классика анального говносервиса.
Держи
https://stackoverflow.com/questions/433071/good-tool-to-visualise-database-schema
100500 реккомендаций
Спасибо, конечно, реально полезно. Но а че по нормализации таблицы можешь сказать?
Без понятия, я вообще SQL только начал изчать. У тебя там разве уже не 3FN?
неужели все это надо держать в голове и тыкать вручную первый раз
алсо поотрубал бы руки, здесь gps_name там name_gps в другой уже names в четвертой imenagps все друг с другом взаимодействует, у этой хуйни код не подсвечивается, только начал вникать а уже чувствую себя дедом из 2007
Так у нормальных БД есть документация по которой искать можно
Или в норм компаниях есть специальный человек который шарит за всю структуру БД но к сожалению у нас почему-то не принято чтобы такой человек работал.
дык спроси у старших, может у вас все же есть документация
хотя бы которая сохранилась с этапа первоначальной разработки, типа тз и прочего
а так если ничего нету то конечно же по сути методами реверс-инжиниринга придется работать
Так ты тут за каждый день группируешь, нужно убрать день только период, и ордер никакой разницы не имеет.
SELECT count(*)
FROM printers
WHERE last_working_day > current_date - INTERVAL '10 day'
>>566371
Я вроде понял что нужен нарастающий итог, погуглил такое решение для постгрес
select last_working_day, sum(cnt) over (order by last_working_day asc rows between unbounded preceding and current row)
from (SELECT last_working_day, count(id) as cnt
FROM printers
WHERE last_working_day > current_date - INTERVAL '10 day'
group by last_working_day) as t1
Есть один отчет, который я поддерживаю. Его надо генерировать регулярно и по отдельности для каждого филиала конторы, но логика одна и та же.
Как это сделано сейчас: есть скрипт на питоне. Его регулярно запускает кронтаб. Скрипт идет в директорию configs, где лежит по json-конфигу на каждый филиал. Проходится for циклом по всем конфигам в директории. Для каждого конфига вытаскивает данные с прописанными в конфиге параметрами из БД. Из этих данных формирует отчет, запаковывает в файл, отправляет имейлом на прописанный в конфиге адрес (менеджера филиала). Потом то же самое для следующего конфига - т.е. филиала. И так далее.
Сейчас пришлю указание от большого начальства перевести всю отчетность на Airflow. Я с ним раньше не работал. Насколько я вижу, по определению джобы в Airflow - это DAG, т.е. они ацикличны. Поэтому наш подход не поедет, и я не понимаю как мне этот процесс переделать в DAG. Так что нужны советы.
В принципе, нам циклы не очень нужны- отчеты филиалов не зависимы друг от друга, их можно генерировать и параллельно. Но филиалов - дохуя и они часто меняются, поэтому создавать руками этот DAG с 50+ ветками я охуею. В Airflow можно как-то программно генерировать структуру DAGа на ходу?
Чтобы считало не за весь период сумму, а накопительно по дням, то есть пример в 1 день 3 отпало, во 2й 2, на 3 4, то будет 1 - 3, 2 - 5, 3 - 9.
Сегодня чет тоже не могу найти тот же пример, вот документация https://www.postgresql.org/docs/current/tutorial-window.html . То есть тут без этого можно rows between unbounded preceding and current row .
Есть таблица в которой хранится хрен знает что с ключом ввиде уникального айди. Во второй таблице эти айди могут встречаться от 0 до бесконечности раз и есть столбец с булевым значением. Мне нужно получить айдишники, рядом с которыми во второй таблице нигде не встречается True. Подозреваю что помимо группировки нужен какой нибудь join, но что-то не выходит.
Блять, сделал пример неправильный. id4 не должно быть в итоговой выборке.
Ты не указал с чем работаешь, я обычно делаю временную таблицу куда копирую айди и false как второе поле по умолчанию, а дальше апдейт state = true с джойном второй таблицы по айди и условию state true для второй таблицы, в итоге если хотя бы раз есть тру, должно стать тру, нет останется false
тип такого
update temp_table
set t1.state = 'true'
from temp_table as t1
join table2 as t2 on t2.id = t1.id
and t2.state = 'true'
> Чтобы считало не за весь период сумму, а накопительно по дням,
Но задача стояла "кол-во принтеров за последние 10 дней", т.е общее
А есть relation между Table1 и Table2? FK? Если да, то тут обычный запрос на table2 where state = False
Если нет, то просто INNER JOIN
SELECT id, state
FROM table2 as t2
INNER JOIN table1 as t1 ON t2.id = t1.id AND t2.id = 'False'
Вернет все id, state где state False и ID встречается table1
Но опять же, если есть relation ввиду FK тогда это не нужно
Это не будет работать, если во второй таблице айди втречается и с True и с False, он выберет строку с false и проигнорит true, но этот айдишник мне не нужен.
PostgreSQL, если ты про СУБД. Не понимаю пример запроса, как ты в update запихал from и join, или это части двух разных запросов.
Про дубликаты ты ничего не сказал.
Один запрос, апдейтить или удалять с Джоном не запрещено) но тут пробуй смотри сам, может синтаксис будет другой, но работать должно как нужно тебе
Вообще такое чувство будто mysql это просто "постгря но чуть похуже", то есть не плохая база но postgres лучше во всем абсолютно и смысла выбрать mysql в новый проект абсолютно нахуй ноль.
В чем я не прав?
Есть некоторое количество говно-CMS для пыхи, которые работают только на MySQL, там выбора и нет. Вот MySQL и берут во всяких говнопроектах типа магазина, очень низкий порог вхождения, думать не надо, таблиц мало, нагрузок нет, админить мышкой легче, чем в постгресе.
Не понял какая связь между админить мышкой и mysql. У мускула еть БД движки под под разные задачи. https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html
Да там есть некий MySQL Workbench, когда-то давно его тыкал, можно было в пару кликов создавать таблицы и связи между ними, даже какая-то диаграмма со схемой была. В постгресе есть PgAdmin, но он более навороченный и сложный.
Мульти-мастер репликация
Говоришь эти три слова в присутствии постгресодебила и ощущаешь пожар
Монгодаун тут как тут.
А нахуя тебе оно надо? По мне так звучит как что-то опасное. У тебя менеджмент конфликта будет как в git бля
Ну ты немного не понял мой вопрос. Если у тебя какой-нибудь вордпресс который нативно работает с мускулом а постргрю поддерживает через костыльный плагин на который ты ставить не хочешь, наверно лучше и правда взять мускуль и не ебаться.
Но тогда у тебя даже нет особо выбора. Я щас говорю о ситуации где ты полностью свободен и можешь выбрать че хочешь, есть ли в таких случаях ризон брать что-то кроме постгри?
Угу, а в MySQL оно работает
Горение уже ощущается
Ну знаешь, можно на это с другой стороны посмотреть. Если тебе нужна функция из постгри, тебе в постгрю. Если сомневаешься бери mysql не ошибешься, в типичном приложении он норм станет без хуйни
Кста говнопроект в вордпрессе и правда лучше на мусукуле будет, там read лучше, а write там все равно раз в неделю
Мне нужен триггер, чтобы при добавлении записи в одну из таблиц, в исходную таблицу сразу же добавлялась запись с нужными полями. Но выскакивает ошибка, мол внешний ключ ссылается на несуществующую запись.
Всё настолько плохо, что надо прям в триггере это делать, или можно как у нормальных людей сделать вызов нужных инсертов на уровне приложения? Можно хотя бы хранимую процедуру написать с этой логикой?
Я делаю учебное задание и мне просто так удобнее было бы, чтобы лишний код не писать. Так что, можно как-то такой триггер сделать?
Парни, как быть с БД в микросервисной архитектуре?
Есть 2 сервиса которые по факту связаны с одной БД. Первый - это бек админки. Второй - это data import, которые периодически обновляет данные в этой БД
Я часто слыхал что когда одна БД привязана более чем к одному микросервису это плохо и вообще пиздец, вот тут статья с Хабра еще на глаза попадалась: https://habr.com/ru/articles/672086/
Но в комментах автора кстати попустили и сказали то "все нармална с интеграционной БД! ты прост лох и не умеешь ее готовить!". Что по этой теме посмотреть и кто прав? Я раньше только с монолитами работал
БД - это обычно source of truth, база это база, что тут говорить. А уж как вокруг нее макаки наговнякали скрипты и как эти скрипты называются на этой неделе - монолитом или микросервисами - глубоко похуй
Разница есть.
Когда пишем в одну базу могут быть проблемы совместимости когда загоняем туда изменения. Но когда баз несколько то могут быть проблемы консистентности.
Это проблемы исключительно макако скриптов, которые в базу смотрят, а не самой базы
раньше все просто было для новичка: просто понимаешь разницу oltp и olap, как организовать хранилище данных и перекидывать туда данные, потом там побственно кубы и аналитические функции, тупо еще расширение sql..
опять же в вузике это давали отдельными лекциями на курсах по теории баз данных..
а сейчас нахуевертили еще всякого..
Есть ли причины использовать postgresql, а не божественный edgedb?
Вообще такое чувство будто posgresql это просто "edgedb но чуть похуже", то есть не плохая база но edgedb лучше во всём абсолютно и смысла выбрать postgresql в новый проект абсолютно нахуй ноль.
В чем я не прав?
Этого не достаточно, чтоб я купился, плохо работаешь, придумай лучше причину
Постгря например сначала удаляет строку а потом делает INSERT с новыми данными даже если поменял лишь 1 колонку. Кто-то говорил что Кассандра вроде как могет, но бля, это колоночная база, какой там нахрен частый апдейт?
Бля, я понимаю сам движок вроде PostgeSQL (?), но пиздец, python для RDBM
Там реляционная модель, просто упрощена в плане навигации.
Less obtuse. Но я думаю упоминание "written in python" быстро отпугивает всех интересующихся at scale.
Нашел лишь отзывы мелких проектов:
https://divan.dev/posts/edgedb/
Там хвалят, говорят реально можно мышкой делать то, что бородатые старики SQL 40 лет учили.
При чём тут GraphQL?
> divan.dev
> This shit is deeply rooted in the russian language too. It’s subconscious. Their tsars had been killing and raping them for centuries, and it became a part of their cultural DNA, which they learned to love. They’ve never had democratic grassroots society mechanisms in their whole history. Learned helplessness. “We’re apolitical”. “It’s our government is bad; we are different”. “We’re for peace”.
Ого, у нас тут прямо база-базон.
Ну, это понаехавший и пидорахии в буржустан, я так понял
Что значит "во всем"?
Как там с поддержкой? Как с коммьюнити? Опен сорс постгрю пилят тысячи человек по всему миру и регулярно вносят апдейты. Тут что?
Как обойти дерево (таблица id-parent_id) без cte? На чистом sql. Это вообще возможно?
> без cte
То есть без рекурсивных запросов? Нет, по-другому никак. Разве что максимальная высота дерева заранее известна, тогда просто портянкой джойнов.
Кого ебёт что ты помнишь. Чтобы выучить дата сцаенс, нужна только самодисциплина и серьёзный настрой. Это как выучить китайский. Его можно хоть за 3 месяца задрочить, если ты железно садишься и каждый день по 8 часов учишь. А если ты несерьёзный человек, обучаешься 15 минут в месяц, любишь сдаваться при любой трудности, то и результаты будут такими же несерьёзными.
В вакансия везде требование экономическое высшее, вопрос больше про вышку и шансы найма с ней.
Вышку похуй.
Для дата саянса лучше всего через дата-аналитику вкатываться. Или в ШАД идти, лол
При чём тут базы данных? В треде про машоб спрашивай.
Да, недавно выпустили.
>В вакансия везде требование экономическое высшее
Требовать они будут на параше. А это просто "пожелание" и не более того. ЖЕЛАТЕЛЬНО экономическое высшее. Это они описывают ИДЕАЛЬНОГО кандидата. Но идеальных кандидатов почти нет, никто не подходит под описание на 100%. Даже если ты хотя бы на 60% подходишь, уже можно подавать заявку. Если оно есть - ХОРОШО, но если его нет... ну нет так нет, проблема пиздец.
Пиздец требования, лол. Да за такое меньше 50$k вообще нахуй нужно.
Вот летом прошлого года устроился на работу, бэк мидол.
На собесе спрашивали не только джойны хевинги да индексы, но и че такое innodb_fsync_threshold, чем отличается синхронная репликация от астнхронной и тд.
А на деле я пишу код который другой отдел ставит как зависимость, и с данными я не работаю напрямую. А на собесе валили пиздец.
Вообще нужно ли лезть в эти дебри или забить хуй и дрючить паттерны?
Петухан задавал тебе дебильные вопросы намеренно чтобы унизить тебя (и чтобы ты почувствовал себя тупым и умерил аппетиты) либо чтобы самоутвердиться
Чёт пробежался по первому курсу, а там задачи из экселя, решил все на обеде + перекуре. А дальше не дают теорию, мол группа ещё не дошла. Открыл весь курс, а там 4 курса по SQL и один ПУСТОЙ по Superset. Дальше идёт теория про свечи и диаграммы. И на последок общие курсы по Питхону. После них: по визуализации данных, anaconda и jupyter notebook - все пустые.
Меня заскамили?
Сверхразумы, хелп с апдейтом данных
У нас есть типичный bulk update одновременно некоторого числа строчек в таблице от Постгрес. На фронте есть набор из сотни строчек, юзер может поменять в одной колонке "комментарий" и потом, нажав на "сохранить изменения", данные для обновы отправляются на бек. Тут есть проблема в том, что если мы пошлем все 100 строк, то разовое обновление такого количества, большая часть из которых в общем-то остались прежними - хреновая затея. Варианта как вижу тут 2:
1. Возложить эту проблему на фронт и заставить его проверят какие именно строки были отредачены, только их на апдейт и слать
2. Фронт посылается массив со всеми 100 строками а бек каким-то образом (каким?) должен понять что обновлять надо только строго определенные
Шо делать в такой ситуации?
Ну или на клиенте сверяешь инпуты с изначальным данными при сабмите или всё на бек, там селектишь опять и сверяешь опять же. Потом в транзакцию.
В целом особой разницы нет, наверное.
А как сверить-то? Я например юзаю питон и драйвер алхимии поверх asyncpg, хоть я и пишу сырой скуль но как мне сверить-то данные без цикла внутри самого питона? Простой запрос внутр искуля на апдейт из селекта был бы такой:
UPDATE shops
SET shops.comment = sub.comment
FROM (
SELECT * FROm some_other_table
) AS sub
WHERE sub.id = shops.id AND sub.comment != shops.comment
Но у меня-то данные с фронта приходят
1. Создаёшь временную таблицу (в твоём случае достаточно чтобы в ней было два столбца: id, comment) через CREATE TEMPORARY TABLE tmp_hueta ...; 2. Вставляешь данные с фронта в эту временную таблицу; 3. Обновляешь основную, использую данные из временной, типа
UPDATE hueta
SET comment = tmp.comment
FROM tmp_hueta tmp
WHERE hueta.id = tmp.id AND hueta.comment <> tmp.comment;
4. Дропаешь временную таблицу (хотя она сама дропнется после закрытия транзакции)
>>692313
Кстати, если строк для обновления не сильно много, то можно даже временную таблицу не использовать а просто все значения в values передать
UPDATE hueta
SET comment = tmp.comment
FROM (VALUES (11, 'comment 1'), (12, 'comment 2')) AS tmp(id, comment)
WHERE hueta.id = tmp.id AND hueta.comment <> tmp.comment
Временные таблицы же создаются в другой схеме? Но именно вот у них будут одинаковые, там конфликтов не будет если несколько разных транзакций начнут их создавать-дропать?
--
--Делаю две простые таблицы:
--Ключ и поле
create table Parent (Id int not null identity primary key, Value int)
--Ключ, внешний ключ и поле
create table Child ( Id int not null identity primary key, IdParent int foreign key references Parent(Id), Value int)
--Добавляю индекс
create index my_Child on Child(Value)
--Заполняю таблицу данными (не отображено)
--Выполняю запрос:
select * from Parent as p
join Child as c on p.Id = c.IdParent
where c.Value = 1
--
Смотрю план запроса, получаю пикрил и ничего не понимаю. Почему сервер так делает? Разве он не должен по дочерней выполнять "Clustered Index Seek", если там некластерный индекс? Спасибо.
Раковые ресурсы
> The ident authentication method works by obtaining the client's operating system user name from an ident server
"Хочу получать пользователя у ident сервера, но запускать его не хочу?" Таблетки. Следующий!
Оптимальный кейс для NoSQL - когда есть небольшое количество уже известных запросов. Например, блог. Там уже примерно понятны сущности - статья, автор, комментарий, и т.д. И какие запросы будут, а-ля "получить все статьи". Плюсы NoSQL - он может масштабироваться хоть до луны, хоть там 2 миллиона статей будет, он всё равно отработает супер быстро.
Оптимальный кейс для SQL - когда есть большое количество разнообразных сущностей и запросов. Например, CRM. И там надо хитро отфильтровать контрагентов по доходам за определенное время.
Короче,
Если тебе нужна гибкость запросов - бери SQL
Если тебе нужна масштабируемость и скорость - бери NoSQL
Заученные шаблоны и пересказы рекламных буклетов разных продуктов, не имеющие ничего общего с реальностью.
NoSQL - это модный 15 лет назад баззворд, под которым успешно раскрутились несколько продуктов. Суть в том, что в отличие от старперских RDBMS, они показали, что их продукт много проще, дешевле в обслуживании, масштабировании и этого достаточно, чтоб быстро-быстро и дешево-дешево выпустить свой, как ты говоришь, блог. Да, нету гибкого языка запросов, но он понадобится послезавтра, а блог надо выпускать и захватывать рынок сейчас.
За это время и NoSQL-решения давно обросли разными языками запросов, и RDMS научились масштабироваться и все остальное, чего там не хватало, в том числе мимикрировать под "NoSQL". В общем, разница между "SQL" и "NoSQL"-решениями - это лишь разница в рекламных буклетах.
Фууу блять это уже извращенство, просто не ТРУ. Я не знаю кто этой хуйнёй страдает. Если ты хотел с SQL работать, так бери SQL. Не совсем понимаю смысла прикручивать еретический язык запросов к NoSQL. Это просто богохульство. Там весь смысл был в том, чтобы структурировать данные под запрос. А в SQL всё наоборот. Испокон веков NoSQL-базы используются чтобы перегонять терабайты данных туда-сюда, их оптимально ставить туда где куча простых запросов. RDBMS начали масштабироваться относительно недавно, только в последние годы появились все эти PlanetScale, Aurora и прочие. А NoSQL в бессерверном варианте уже миллион лет работают. Философия всё равно другая, как бы кто не мимикрировал.
С религиозными тараканами в голове - тебе не сюда, а в церковь или к врачу. Если же ты снимешь шоры, и посмотришь из чего состоит и всегда(!) состояли RDMS - то будешь согласен со всем вышесказанным.
Я не не хочу его запускать. Я не могу его запустить рут прав же нету ебана. А метод ident оставить надо не мне лично , такое задание.
Мы вам перезвоним
Я хочу сливать в БД различную информацию (id, время, параметры) + будет всякая инфа по foreign ключам (хз как корректно называется) + хочу сливать изображение (не весь кадр, а обрезанную область).
Какую лучше БД взять? Слив думал делать на ту же машину, где происходит обработка (т.е. типа MySql использовать). На машине есть ссд. Всякие костыли типа csv не хочу, бесит и хуево масштабируется.
Возможно, целевая система будет AstraLinux. Там сертифицирован Postgresql и MariaDb. Пострес на локалхосте эффективен или хуйня?
>Какую лучше БД взять?
Любая IoT/Time series-база данных. Apache IoTDB, InfluxDB, CrateDB, Riak TS и проч. По сути, то что ты хранишь - это временной ряд. Главный минус и PostgreSQL и MariaDB они не очень хорошо работают с временными рядами (ебать у них даже название "реляционная ДБ"), если в базу часто писать, они будет быстро разрастаться и подтормаживать. Придётся чистить от старого говна. Плюс, там не получится писать запросы в стиле "получить усредненные данные с камер 1, 2 за последний месяц, с интервалом один час".
Попробуй ебать ради эксперимента запиши в марию дб, запиши свои данные (id, время, и проч) и попробуй сделать запрос "верни 10 усредненных результатов за неделю с интервалом 10 минут". И увидишь какая хуйня получится. Можно сделать на постгре, но там будет костыль на костыле. Кое-как через жопу работать.
Думаю, что для локалхоста у постгреса есть подключение через юникс домаин сокетс
>>698246
Спасибо за инфу, читнул немного про тайм-сериес, буду знать.
Слив инфы я хотел сделать как помойку, чтобы потом все это говно медленно разгребать. Даже думал сессии сделать. Мне очень хочется использовать реляционную бд , т.к. задача хорошо бьётся на несколько таблиц
А он на 200+ строк, и текстовый редактор в ssms просто никакой, едва ли лучше блокнота, никак не могу нормально разобраться.
В том же notepad++ табуляция лучше работает, да и скобки подсвечиваются, есть ли какие-нибудь другие редакторы, чтобы все красиво было?
А то я привык, что в pycharm с питоном ахуенно работать, а тут такая залупа от майков...
Ты ещё раз прочитай, я явно указал вопрос:
> В том же notepad++ табуляция лучше работает, да и скобки подсвечиваются, есть ли какие-нибудь другие редакторы, чтобы все красиво было?
Ты еще раз прочитай свой же вопрос, в нем же ты дал ответ и привёл пример другого редактора
Пиздец ты сверхразум. Еще раз прочитай свое сообщение. Там еще один редактор упоминается
Это правда, не говнищем от жидбрейнс же пользоваться
>>А то я привык, что в pycharm с питоном ахуенно работать, а тут такая залупа от майков...
Там разве datagrip в комплекте не идет?
ПЕРЕКАТ >>2701507 (OP)
ПЕРЕКАТ >>2701507 (OP)
ПЕРЕКАТ >>2701507 (OP)
ПЕРЕКАТ >>2701507 (OP)
Это копия, сохраненная 14 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.