А не подскажете в чем профит от json в рсубд?

Насколько я понимаю - все там хранят неструктурированные документы

3 день не могу решить запрос... http://sqlinfo.ru/forum/viewtopic.php?pid=45793#p45793

А не подскажете в чем профит от json в рсубд?

вопрос скорее философский. есть мнение (и не только моё) что вся мода на NoSQL СУБД закончится, как только РСУБД сделают хранение и обработку неструктурированных данных 1) возможной и 2) удобной

с 1) уже справились. теперь идёт работа над 2)

постгрес считает, что 2) нужно делать реализацией SQL/JSON стандарта. Который, на мой взгляд, неудобный и громоздкий

в мускле решили зайти с другой стороны — X Protocol и X DevAPI. посмотрели на API MongoDB и сделали что-то похожее

вопрос скорее философский. есть мнение (и не только моё) что вся мода на NoSQL СУБД закончится, как только РСУБД сделают хранение и обработку неструктурированных данных 1) возможной и 2) удобной

nosql - это не хранение документов, ну честное слово

nosql - это не хранение документов, ну честное слово

Ну один из вариантов. И скажу очень удобный

У рсубд кажется ещё 3й недостаток - масштабирование

спс, но не получаеться. если не сложно покажите 2 варианта... CTE вообще хз...

) tsya.ru ) SELECT `transactions`.`base_id`, SUM(`transactions`.`amount_fee`) AS short_amount FROM `transactions` LEFT JOIN base ON (`base`.`id` = `transactions`.`base_id`) WHERE `transactions`.`loan_type` = 1 GROUP BY `transactions`.`base_id` SELECT `cte`.`base_id`, `cte`.`short_amount` FROM ( SELECT `transactions`.`base_id`, SUM(`transactions`.`amount_fee`) AS short_amount FROM `transactions` WHERE `transactions`.`loan_type` = 1 GROUP BY `transactions`.`base_id` ) AS cte LEFT JOIN base ON (`base`.`id` = `cte`.`base_id`) И, наконец, главный вопрос. Зачем делать джойн, который не используется (из таблицы не подтягивается вообще ничего)?

Просто выше было о том, что сделали обновление содержимого json не полной перезаписью... и о том, что в pg это по-другому. Я понимаю, почему и зачем в pg пишется целая новая запись в таблицу - для выполнения версионирования строк. И мне кажется это правильным. С другой стороны, я понимаю, что ради изменения 1 атрибута json в 1 поле таблицы - перезаписывать целиком строку - накладно. Но вижу в этом моменте некоторое противоречие.. Некоторое противоестественное применение рсубд... Кажется тут нужно что-то концептуально новое, а не просто вкорячивать json в бд.

И моё виденье будущего - sql like синтаксис для nosql.

) tsya.ru ) SELECT `transactions`.`base_id`, SUM(`transactions`.`amount_fee`) AS short_amount FROM `transactions` LEFT JOIN base ON (`base`.`id` = `transactions`.`base_id`) WHERE `transactions`.`loan_type` = 1 GROUP BY `transactions`.`base_id` SELECT `cte`.`base_id`, `cte`.`short_amount` FROM ( SELECT `transactions`.`base_id`, SUM(`transactions`.`amount_fee`) AS short_amount FROM `transactions` WHERE `transactions`.`loan_type` = 1 GROUP BY `transactions`.`base_id` ) AS cte LEFT JOIN base ON (`base`.`id` = `cte`.`base_id`) И, наконец, главный вопрос. Зачем делать джойн, который не используется (из таблицы не подтягивается вообще ничего)?

спс, но JOIN мне надо что бы именно ту запись обновить где base.id = transaction.base_id + не вижу UPDATE

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

Просто выше было о том, что сделали обновление содержимого json не полной перезаписью... и о том, что в pg это по-другому. Я понимаю, почему и зачем в pg пишется целая новая запись в таблицу - для выполнения версионирования строк. И мне кажется это правильным. С другой стороны, я понимаю, что ради изменения 1 атрибута json в 1 поле таблицы - перезаписывать целиком строку - накладно. Но вижу в этом моменте некоторое противоречие.. Некоторое противоестественное применение рсубд... Кажется тут нужно что-то концептуально новое, а не просто вкорячивать json в бд.

MVCC можно реализовывать по-разному. В PostgreSQL был изначально выбран подход с immutable строчками. И теперь они от этого страдают (но втихую, они не любят об этом расказывать публично). В InnoDB (и Oracle) был выбран подход с in-place обновлениями + UNDO log. И он лучше подходит для OLTP нагрузок. А в контексте JSON ещё и дополнительные плюшки вылезают

локи подходят лучше оптимистичной блокировки?

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

Ой ну сорри я ведь тут писал http://sqlinfo.ru/forum/viewtopic.php?pid=45793#p45793 я думал ты это читал...

а так вроде помогли вот подправил немного, вроде работает... UPDATE base b JOIN (SELECT base_id, SUM(amount_fee) as amount_fee FROM transactions WHERE loan_type = 1 GROUP BY 1) t ON b.id=t.base_id set b.short_amount = amount_fee; UPDATE base b JOIN (SELECT base_id, SUM(amount_fee) as amount_fee FROM transactions WHERE loan_type = 2 GROUP BY 1) t ON b.id=t.base_id set b.long_amount = amount_fee;только на сколько верно по твоему? и можно ведь через 1 запрос сделать..., спс. конечно

MVCC можно реализовывать по-разному. В PostgreSQL был изначально выбран подход с immutable строчками. И теперь они от этого страдают (но втихую, они не любят об этом расказывать публично). В InnoDB (и Oracle) был выбран подход с in-place обновлениями + UNDO log. И он лучше подходит для OLTP нагрузок. А в контексте JSON ещё и дополнительные плюшки вылезают

Ну в оракл тоже не все хорошо с undo

snapshot to old же

И моё виденье будущего - sql like синтаксис для nosql.

но да, сейчас многие NoSQL СУБД пытаются отрастить себе SQL. всё смешалось в доме Облонских, как обычно

snapshot to old же

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

Эм, какие NoSQL отращивают себе SQL?

Tarantool?

Cassandra + CQL?

в кассандре всегда был cql

"0.8, released Jun 2 2011, added the Cassandra Query Language (CQL), self-tuning memtables, and support for zero-downtime upgrades[9]"

а Column Family появился и того позже

гайс, а мускул сам оживёт, если например в него пишут по 100метров в секунду инсертами, место кончилось, я докинул места в раздел где хранится всё(в нём всё и кончилось)? или трупъ и рестарт онли?

гайс, а мускул сам оживёт, если например в него пишут по 100метров в секунду инсертами, место кончилось, я докинул места в раздел где хранится всё(в нём всё и кончилось)? или трупъ и рестарт онли?

не оживёт. мы пытались это исправить в percona server, но там всё сложно

не оживёт. мы пытались это исправить в percona server, но там всё сложно

я правильно понимаю, это ограничение INNODB?

да

я правда не уверен, что другие СУБД лучше поведут себя в такой ситуации. главная проблема в том, что когда мы поняли, что место на диске закончилось и транзакцию нужно откатить, на откат транзакции вполне может понадобится место на диске, которого уже нет

Всем привет! Помогите с этим разобраться.

Пытаюсь подключить БД(mysql) к LibreOffice через JDBC но вижу это ☝️

а jdbc драйвер загружен?

написано что нет

привет, коллеги адекватно ли делать поле enum в одной таблице(таблица1), а потом делая это же поле в другой таблице(таблица2) и ссылаться на поле из таблицы1. Меня смущает тип поля. Как думаете?

привет, коллеги адекватно ли делать поле enum в одной таблице(таблица1), а потом делая это же поле в другой таблице(таблица2) и ссылаться на поле из таблицы1. Меня смущает тип поля. Как думаете?

в общем и целом, использование ENUM считается плохой практикой. вот тут рассказывают почему: http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

в общем и целом, использование ENUM считается плохой практикой. вот тут рассказывают почему: http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

ок. а что по моему вопросу?

я думал это отвечает на вопрос. ENUM использовать нежелательно, в том числе и в данном конкретном случае по тем же причинам, что и в статье

я думал это отвечает на вопрос. ENUM использовать нежелательно, в том числе и в данном конкретном случае по тем же причинам, что и в статье

спасибо.

а jdbc драйвер загружен?

В этом то и проблема! Скачал, указал путь до папки, перезапустил LibreOffice все равно пишет, что не загружен..?

Товарищи, кто-нибудь использует event scheduler в Galera cluster?

Оно вообще работает?

какое-то время назад не работало. не знаю, как сейчас

но там нет красивого и универсального решения

То есть нельзя просто бахнуть event_scheduler = on и всё. Жаль.

кому-то нужно, чтобы ивенты выполнялись на всех нодах. кому-то нужно, чтобы ивенты выполнялись только один раз на originating node

а кому-то и то, и другое

я пытаюсь найти баг репорт с обсуждением

а вообще они что-то там исправляли в этом плане: https://bugs.launchpad.net/codership-mysql/+bug/1312618

чот с майскл на постгресс запрос переписать пытаюсь

INSERT INTO split_test_session (uuid, test_name_id, test_value, user_id, started_at, ended_at) VALUES ('156dce32a5f16ee2aafc3580ea230ab1', 18, 1, 0, '2017-07-03 17:00:00', '2017-07-03 17:00:01') ON CONFLICT (uuid, test_name_id) DO UPDATE SET ended_at = GREATEST(ended_at, VALUE(ended_at));

[42702] ERROR: column reference "ended_at" is ambiguous

on duplicate key update end_datetime = greatest(end_datetime, values(end_datetime))

Вот такой по сути

типа двусмысленно

как ему тогда указать что записывать в ended_at правильно

чтобы он сравнил текущее значение с уже существующим

а вообще они что-то там исправляли в этом плане: https://bugs.launchpad.net/codership-mysql/+bug/1312618

Это поинтереснее уже. Возможно даже есть шанс, что оно уже есть в моей Mariadb

Надо потестить создание ивентов.

INSERT INTO split_test_session (uuid, test_name_id, test_value, user_id, started_at, ended_at) VALUES ('156dce32a5f16ee2aafc3580ea230ab1', 18, 1, 0, '2017-07-03 17:00:00', '2017-07-03 17:00:01') ON CONFLICT (uuid, test_name_id) DO UPDATE SET ended_at = GREATEST(ended_at, VALUE(ended_at));

GREATEST(split_test_session.ended_at, excluded.ended_at) ?

https://www.postgresql.org/docs/9.5/static/sql-insert.html#SQL-ON-CONFLICT

только как-то странно выглядит, что excluded называют новые значения

хм

а в первой части указания имени таблицы-тоже обязательный элемент?

хз, только что гуглом это все нашел

проверил

без указания таблицы-пишет ту же ошибку

GREATEST(split_test_session.ended_at, excluded.ended_at) ?

а так всё ок

Надо потестить создание ивентов.

я залез в код — там пишут, что поведение event scheduler в галере соответствует поведению в обычной репликации в том виде, как описано здесь: https://dev.mysql.com/doc/refman/5.7/en/replication-features-invoked.html

хех, спасибо. Я видел про этот экслудед, но почему то решил что это не о том

я залез в код — там пишут, что поведение event scheduler в галере соответствует поведению в обычной репликации в том виде, как описано здесь: https://dev.mysql.com/doc/refman/5.7/en/replication-features-invoked.html

Интересно как теперь понять, как оно в Марии

Интересно как теперь понять, как оно в Марии

думаю, что так же. они мало что в галере изменили

думаю, что так же. они мало что в галере изменили

Ну от 5.7 ветки уже сильное отличие AFAIK

только не в галере

В этом то и проблема! Скачал, указал путь до папки, перезапустил LibreOffice все равно пишет, что не загружен..?

Версию другую попробуй

Версию другую попробуй

Три версии попробовал, результат тот же(

Всем привет. Подскажите, пожалуйста, как решить следующую задачу. У меня есть таблица, в которой хранятся некоторые ключи и значение для них. Это значение по ключу записывается раз в месяц. Например: id key value 1 item1 10 2 item2 5 3 item1 12 4 item2 7 Задача такая. Посчитать сумму value для каждого ключа за 12 месяцев (за год) и за всё время. Как это правильно сделать?

даты-то есть в таблице?

+

MAX(date)

Это для посл. месяца.

То есть, поле называется date

select sum(value) where (условие с date)

Благодарю.

Правильно ли я понимаю, чтобы посчитать сумму по item'ам, нужно добавить GROUP BY key?

да

Спасибо =)

SELECT key, SUM(value) FROM table WHERE date >= ( SELECT MAX(date) - INTERVAL '12 MONTH' FROM table ) AND key='blah-blah' GROUP BY key; Мб, кому пригодится: сумма значений по ключу за посл. 12 мес. Условие нужно немного скорректировать, конечно.

Я понимаю, что запрос простой. Другое дело, когда ты знаешь это в теории, а на практике с вложенными запросами не работал. Самое забавное: вчера просидел над запросом типа UPDATE from SELECT целый день.

Потерял много времени. Мб, кому-то это время сэкономлю.

Оу...update/insert/delete с вложенным запросом плохая идея. Результат вложенного запроса- некая виртуальная/временная таблица (существует строго в рамках выполнения запроса), следовательно изминить этот результат ты не можешь. Но вот использовать его как указатель на то с цемента работаешь - вполне (типа Update 1 from 1 where 1.id in (select)

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