ЛХ
Size: a a a
2020 July 05
ОA
но отсутствие функций вроде split, приколы вроде string + string = 0
честно говоря не понимаю от куда такой негатив к выражденному примеру с суммированием строк. Ну есть такая особенность. Она не является решающим фактором при выборе СУБД :)
ЛХ
честно говоря не понимаю от куда такой негатив к выражденному примеру с суммированием строк. Ну есть такая особенность. Она не является решающим фактором при выборе СУБД :)
таких мелочей много. в том же постгресе есть больше банальных функций, которые значительно упрощают работу
ОA
я где-то сказал о том что монга сложнее? У меня ощущение что мы где-то рассинхронились в обсуждаемых темах.
ЛХ
Я не сказал что mongo не нравится. Я сказал что есть желание от него уйти. Желание обосновано кучкой причин: от трудности его использования в старом приложении до устранения дополнительной точки отказа (которая у нас присутствует только из-за одной коллекции)
от трудности его использования
РR
Основная причина JSON (есть желание избавиться от зоопарка технологии, т.е. mongo.) + в ряде случаев есть прирост производительности на 5.7.
Понял. А 8.0 не подошла по каким-то причинам? Там вроде как CTE, оконные функции и json он еще лучше работает.
ОA
от трудности его использования
это выдирание фразы из контекста. Основная часть - "в старом приложении". И там есть проблема с библиотекой. Вдаваться в подробности не буду.
ЛХ
это выдирание фразы из контекста. Основная часть - "в старом приложении". И там есть проблема с библиотекой. Вдаваться в подробности не буду.
а. понял теперь.
ОA
Понял. А 8.0 не подошла по каким-то причинам? Там вроде как CTE, оконные функции и json он еще лучше работает.
Мы пробуем обновляться небольшими шагами. Даже обновление на 5.7 как можно видеть приносит разные ньюансы. Может дальше будет и 8.0.
IZ
Dzog
я могу ошибаться, но в мускуле "+" это арифметическая операция
Именно так и есть
IZ
Основная причина JSON (есть желание избавиться от зоопарка технологии, т.е. mongo.) + в ряде случаев есть прирост производительности на 5.7.
JSON не нужен в реляционной СУБД....
ОA
JSON не нужен в реляционной СУБД....
Это слишком безапелляционное заявление. Попахивает холиварами и субъективщиной :) не готов в это ввязываться, сорри :)
🅚
А реально вообще бд нереляционную перенести на реляционную с минимальными затратами, дабы ручками не заполнять таблицы?
IZ
А реально вообще бд нереляционную перенести на реляционную с минимальными затратами, дабы ручками не заполнять таблицы?
Вообще, реально, но проблема в затраченных усилиях
РR
JSON не нужен в реляционной СУБД....
Это imho удобно как минимум, даже если внутри системы json не нужен, но если ваша система общается через REST с другой системой, логи запросов и ответов с передаваемыми json файлами удобно хранить в той же БД и бэкапить вместе с базой.
IZ
Это imho удобно как минимум, даже если внутри системы json не нужен, но если ваша система общается через REST с другой системой, логи запросов и ответов с передаваемыми json файлами удобно хранить в той же БД и бэкапить вместе с базой.
Это не задача СУБД - хранить логи. Но даже если так, как ты про ним что-то искать будешь?
РR
Задача. Админам так удобнее обычно. Именно потому что искать по ним попроще чем по файлам. Я ничего искать не буду, помогу админу SQL написать в крайнем случае.
C
Задача. Админам так удобнее обычно. Именно потому что искать по ним попроще чем по файлам. Я ничего искать не буду, помогу админу SQL написать в крайнем случае.
используй кликхаус https://clickhouse.yandex/ для логов, прекрасно подходит под это🤔
