@acromegale .. вы могли бы привести пример? пробую читать https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_found-rows https://habrahabr.ru/post/64655/ и не нахожу такого применения. видимо нужно более внимательно читать

Функа возвращает результат выполнения, все просто

Там и примеры есть в мануале

что именно? выборку вставку? это ясно. хочеться сделать небольшую форму в админку для дебага и проверки данных, но чтобы случайно никто ничего не поломал..

Вставку и выборку. Update и выборку

Ребят, подскажите пожалуйста как лучше сделать следующее: есть бд - mysql. в ней таблица - пользователи, у которых поля - логин, пароль и еще таблица товар - название, описание Мне нужно реализовать как-то любимые товары, тоесть чтобы у конкретного пользователя были некоторые товары, как это со стороны БД делается?

Зто пишется запрос, который всё возвращает

тоесть один запрос может вернуть данные из двух разных таблиц?

Зто пишется запрос, который всё возвращает

Ты напиши пару развернутых ответов. И бум их просто копипастить. Или бота приделаем и пусть он по команде выдает

тоесть один запрос может вернуть данные из двух разных таблиц?

Да, хоть из 20 таблиц... Но тете придется изучить язык SQL

Ребят, подскажите пожалуйста как лучше сделать следующее: есть бд - mysql. в ней таблица - пользователи, у которых поля - логин, пароль и еще таблица товар - название, описание Мне нужно реализовать как-то любимые товары, тоесть чтобы у конкретного пользователя были некоторые товары, как это со стороны БД делается?

с моей колокольни представляется наиболее разумным завести третью таблицу связей пользователь-товар.

/help

/stat@combot

combot.org/chat/-1001045152752

А есть какие-то способы сохранить построенную группировку на уровне mysql для последующей выборки из нее? Есть таблица с парой десятков миллионов данных, их нужно сгруппировать и дальше двигаясь чанками обработать (т.к. в память все даже после группировки не влезет). Как я понимаю группировка будет вызываться на каждой выборке чанка (limit - offset)

временная таблица?

И зачем все в память собирать? Делаем запрос и построчно читаем. Если результат запроса большой - просто все в темп свалится

Приветствую! Дайте пожалуйста совет. Необходимо изменить структуру таблицы postgresql96 (горячей, данные постоянно обновляются в этой таблице), добавить новый столбец. Боюсь если это делать, то придятся отключать пользователей и производить изменения Как это сделать лучше, что бы минимизировать влияние на пользователей?

А альтер лочит вроде таблицы. Если процесс долгий то можно через подмену таблиц.

?

Добавление с null

Оно быстро пройдет

Этож не мускуль

Откуда понабежали?

А, из девопса

А альтер лочит вроде таблицы. Если процесс долгий то можно через подмену таблиц.

т.е. создать новую таблицу, с необходимыми изменениями, заполнить её из исходной данными, и потом сделать подмену?

А, из девопса

я да, из девопса прибежал )

т.е. создать новую таблицу, с необходимыми изменениями, заполнить её из исходной данными, и потом сделать подмену?

Добавить столбец заполненный null

Добавить столбец заполненный null

не создавая новой таблицы?

т.е. создать новую таблицу, с необходимыми изменениями, заполнить её из исходной данными, и потом сделать подмену?

Да, но как выше заметили, нуллы быстро добавляются

не создавая новой таблицы?

Да, просто альтером

не создавая новой таблицы?

Да

благодарю

Этож не мускуль

у мускуле добавление колонки с null тоже довольно быстро еще с 5.6

так что не надо тут...

Ну да... На TokuDB только если

у мускуле добавление колонки с null тоже довольно быстро еще с 5.6

я последнюю трогал еще 5.1

или даже более ранюю версию

так что стереотипы остались :)

c 5.6 подвезли online ddl, кратковременная блокировка будет только в самом конце на применении изменений, но это все же лучше чем полный мейнтенс на время альтера

ну, надо сказать, что в mysql добавление невиртуальной колонки всё-таки перестраивает таблицу, хоть и без блокировок. а в postgresql добавление nullable голонки это in-place, metadata-only операции

что не отменяет того факта, что все эти "стереотипы" 10-летней и большей давности несколько доставляют

это как если бы я ходил и везде рассказывал, что в постгресе нет репликации. ну, нуачо, в 8.4 же не было. стереотипы, вся хурма

Ну, в мускуле есть разные движки. Для того же току это metadata-only операция. В экспериментально добавленном роксе вроде тоже, но это не точно))))

это как если бы я ходил и везде рассказывал, что в постгресе нет репликации. ну, нуачо, в 8.4 же не было. стереотипы, вся хурма

5.6 же недавно вышла )

но вообще надо да, почитать чо там нового завезли :)

5.6 же недавно вышла )

ну да, года 3 как))))

да отож. 4 года не срок, кто понял жизнь, тот не спешит

Ещё бы MySQL научился эти onlyne-ddl реплицировать так же в фоне, цены бы ему не было

а то толку получается мало - вроде как и ничего не блокировалось, но слейва ушли в дофигищща отставания по реплике

для этого завезли gh-ost и pt-osc

ну, тяжкие они... Не проще ли при добавлении например колонки на слейвах сначала добавить колонку в таких случаях, а потом на мастере и скипнуть ошибку "такая дрянь есть" на слейвах?

ну, тяжкие они... Не проще ли при добавлении например колонки на слейвах сначала добавить колонку в таких случаях, а потом на мастере и скипнуть ошибку "такая дрянь есть" на слейвах?

да ты наркоман

сдается мне там опять блокировка будет на время обновления всего этого

да ты наркоман

не, тока бухаю.

вообщем мускуль это больно

сдается мне там опять блокировка будет на время обновления всего этого

никаких блокировок

никаких блокировок

а как ты себе представляешь это ? пока не изменился слейв на мастере нельзя трогать таблицу пока она не обновиться.

соответсвенно на все время обновлений обоих таблиц - хер

не ?

а как ты себе представляешь это ? пока не изменился слейв на мастере нельзя трогать таблицу пока она не обновиться.

кто сказал? Ты отстал от жизни)))) На слейве может быть число колонок большее, чем у мастера

ERROR: S client not available

это при какой репликации ?

при любой

О_О

нафиг так жить

не не, я лучше с постгресом буду жить дальше

Слон слишком умным себя считает, а это плохо... Ну да ладно, ща в вечный холивар скатимся. Мне например слон не нравится совсем

слишком умным это где ? :)

Форс индексы никак не поставишь, например. А я хочу! Я вообще люблю отстреливать себе конечности

не не, я лучше с постгресом буду жить дальше

в постгресе специально для этого завезли логическую репликацию. чтобы разное число колонок на слейве и мастере, rolling schema updates, cross-version upgrades и вот это всё, с чем сталкиваются люди, которые базульки не только на локалхосте запускают

я про логическую репликацию в курсе

поэтому и уточнял

воот, ну её не зря придумали

в постгресе специально для этого завезли логическую репликацию. чтобы разное число колонок на слейве и мастере, rolling schema updates, cross-version upgrades и вот это всё, с чем сталкиваются люди, которые базульки не только на локалхосте запускают

не завезли, а нагло спиздили из pg-logical

я думаю так правильнее

Ну, в мускуле то ж самое)))) Там целая тьма вариантов иметь разное количество колонок и разные типы данных в них.

правда ей до мусклвской репликации пока как до китая раком. но лиха беда начало

в мускуле есть же разные репликации

не завезли, а нагло спиздили из pg-logical

Это опенсорс. Ничего не крадётся, всё просто используется

в мускуле есть же разные репликации

На гдидах и позициях только. Различен лишь формат бинлога. Причём различен динамически, можнно на лету менять.

ок

не завезли, а нагло спиздили из pg-logical

вот тут рассказывают, чем встроенная в postgresql 10 отличается от pglogical. невесёлое такое чтиво: https://blog.2ndquadrant.com/pglogical-logical-replication-postgresql-10/

А есть какие-то способы сохранить построенную группировку на уровне mysql для последующей выборки из нее? Есть таблица с парой десятков миллионов данных, их нужно сгруппировать и дальше двигаясь чанками обработать (т.к. в память все даже после группировки не влезет). Как я понимаю группировка будет вызываться на каждой выборке чанка (limit - offset)

View

А есть какие-то способы сохранить построенную группировку на уровне mysql для последующей выборки из нее? Есть таблица с парой десятков миллионов данных, их нужно сгруппировать и дальше двигаясь чанками обработать (т.к. в память все даже после группировки не влезет). Как я понимаю группировка будет вызываться на каждой выборке чанка (limit - offset)

Ну чуть позже расскажу..

А есть какие-то способы сохранить построенную группировку на уровне mysql для последующей выборки из нее? Есть таблица с парой десятков миллионов данных, их нужно сгруппировать и дальше двигаясь чанками обработать (т.к. в память все даже после группировки не влезет). Как я понимаю группировка будет вызываться на каждой выборке чанка (limit - offset)

во-первых ,тебе надо понять, что никакие данные запроса в память не кладутся целиком, запрос просто выполняется, и результаты передаются клиенту. Это может быт очень длительный процесс. 2) LIMIT/OFFSET — да, не решение. Тут ты прав. 3) То, что тебе нужно — это простой курсор. Это значит, ПРОСТО ВЫПОЛНИТЬ ЗАПРОС (один раз) и выбирать из него данные. Далее, есть два варианта технического оформления. 1) клиентский курсор — просто выполнить запрос , выбирать данные и обрабатывать построчно. Соединение с БД при этом будет занято на должное время выполнения запроса. Разрывать его нельзя. 2) Так называемый серверный курсор, или просто курсор — это то, что описано тут https://dev.mysql.com/doc/refman/5.7/en/cursors.html как там с закрытием соединения, не знаю, наверняка, нельзя, но перемежать FETCHи из курсора с другими запросами вроде бы можно.

Приветствую! Дайте пожалуйста совет. Необходимо изменить структуру таблицы postgresql96 (горячей, данные постоянно обновляются в этой таблице), добавить новый столбец. Боюсь если это делать, то придятся отключать пользователей и производить изменения Как это сделать лучше, что бы минимизировать влияние на пользователей?

ПРосто дать alter table add column, в какой-то момент таблица заблокируется на не очень большое время, потом разблокируется. Новые колонки лучше делать NULLABLE, иначе процесс добавления может быть очень долгим, так как все данные будут копироваться. Можно и пользователей отключить, или делать это ночью/ вдругое нерабочее время

т.е. создать новую таблицу, с необходимыми изменениями, заполнить её из исходной данными, и потом сделать подмену?

Это неприемлимо, если таблица постоянно меняется...

5.6 же недавно вышла )

Да, ещё 10 лет не прошло...

ПРосто дать alter table add column, в какой-то момент таблица заблокируется на не очень большое время, потом разблокируется. Новые колонки лучше делать NULLABLE, иначе процесс добавления может быть очень долгим, так как все данные будут копироваться. Можно и пользователей отключить, или делать это ночью/ вдругое нерабочее время

делается ночью, но на будущее хочется добиться минимума прерывания для пользователей, т.к. они работают круглосуточно