JSON тип данные в MySQL, в чем минус?

0. Использование JSON в MySQL, это как бы круто, т.к. из Mysql можно сделать MongoDB. И тогда спрашивается, зачем нужна последняя?

1. Вообще мимо, по JSON полям можно сделать индексы.

2. Вы давно с MySQL работали? Документация. Не нравится мускл, вперед к Maria.

P.S. если не знаете, лучше не пишите. Или хотя бы делайте это не с таким умным видом.

Из MySQL неможно сделать MongoDB и вообще - конкретно это Ваше утверждение ничем не подкреплено. Только то, что и в MySQL и поддерживается одинаковый формат данных - не говорит о взаиомозаменяемости одной базы другой.

Какие? Ссылку на документацию по этому вопросу, пожалуйста.

Я то как раз недавно, в отличии от Вас видимо :))) Вы понимаете, чем отличается Maria от MySQL и тот момент, что Maria была реализована явно не с целью и желанием реализовать поддержку SQL-стандартов, которой нет в MySQL? И уж явно никоим дрыком на данный момент в MariaDB SQL-2016 не реализован.

Кто из нас не знает на самом деле - мы сейчас выясним...

MongoDB - это документо-ориентированная БД в которой документы представляют из себя JSON файлы. Т.к. MySQL поддерживает JSON поля, то по факту, в общем случае, можно документы (aka таблицы) Mongo, разместить в JSON полях MySQL.

Документация, видимо поиском лень пользоваться.

As noted elsewhere, JSON columns cannot be indexed directly. To create an index that references such a column indirectly, you can define a generated column that extracts the information that should be indexed, then create an index on the generated column, as shown in this example

Как отмечалось ранее - JSON-колонки не могут быть проиндексированы напрямую

Дак собственно выяснять то и нечего, ваша основная претензия это то, что в MySQL не реализован стандарт. По такой логике использовать NoSQL технологии (или прочие), для которых нет стандартов - нельзя?

Видимо все ваши работы остались на столе у преподавателей универа.

А вы судя по всему интересный собеседник с диким ЧСВ

MySQL никак не может заменить монгу, хотя бы по той причине, что не может (об этом ниже) индексировать JSON-поля. По такому принципу "замены" о котором Вы говорите - можно БТР заменить тарктором, если к нему прикрутить пулемёт, сходства будут примерно аналогичные.

CREATE TABLE jemp (
     c JSON,
     g INT GENERATED ALWAYS AS (c->"$.id"),
     INDEX i (g)
);
EXPLAIN SELECT c->>"$.name" FROM jemp WHERE g > 2 ORDER BY c->"$.name"\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: jemp
   partitions: NULL
         type: range
possible_keys: i
          key: i
      key_len: 5
          ref: NULL
         rows: 2
     filtered: 100.00
        Extra: Using where; Using filesort
1 row in set, 1 warning (0.00 sec)

Мои работы до сих пор радуют некоторых крупных заказчиков, как местных так и иностранных (включая международные компании), некоторые из которых входят в ТОП Форбс'а. Некоторых других не менее радуют ряд специалистов, подготовленных лично мной, в т.ч. специалистов международного уровня.

Как же сложно с вами общаться. Вы сами пробовали создавать индекс? Каким образом база построит вам индекс по всему JSON полю, которое в принципе может иметь любую структуру?!

Документацию прочитайте повнимательней, там даже пример по созданию индекса (видимо дальше первого абзаца вы не пошли?)

А теперь вопрос: какого хера, специалист такого уровня как вы, сидит, и несет такую херь?! Или вы слегка преувеличили свои регалии? Или вам просто повезло? Или несмотря на такие заслуги вы херовый специалист? Или вы просто специалист к конкретной области, а считаете себя эрудитом и знатоком во всех областях?

В какой ситуации вам понадобиться создавать индексы по всем ключам JSON поля (или документа в случае с Mongo), если запросы по факту будут делаться по конкретным полям?

С монго вы судя по всему тоже не работали

Например так, один из вариантов индексации JSON-данных. 3 строчки про GIN. Что нам MySQL предоставляет в качестве альтернативы GIN-индексам... дайте подумать... примерно, ничего?
Прочитайте документацию по другим БД, и тогда вопрос "как можно индексировать JSON-поля?" отпадет сам собой.

Если немного подумать, то херь несёте именно Вы, достаточно взять одно только высказывание, про то, что "MongoDB можно заменить на MySQL без каких либо проблем". Вы берете во внимание исключительно какой-то удобный для подобного утверждения пример, забывая примерно обо всех индивидуальных особенностях этих двух БД. Таких как скорость обработки данных например, общую концепцию работы и так далее. Если бы базы так легко (как вы думаете) взаимозаменялись - достаточно было бы одной БД а MongoDB вероятнее всего, вообще не появилась и вряд ли бы она стала развиваться, а какие-то люди (исходя из вашей логики) - не понимающие прописной истины, которая заключается в том, что в MySQL тоже есть JSON (или возможность туда его добавить) - не стали бы вкладывать сотни тысяч $$$ в развитие MongoDB.

Это ещё один момент, который показывает крайне не высокий уровень вашей квалификации, который вы так усердно пытаетесь приписать мне. Конкретными - поля (ключи) становятся исключительно в момент запроса, а сама по себе структура - может многократно и динамически меняться в режиме "от случая к случаю". Есть миллион вариантов, при которых нам может понадобиться поиск по динамически выбранному набору полей, который при этом будет "всеми полями" для одного отдельно взятого документа. И индексацию в этом случае, можно проводить так же - динамически, главное делать это с головой, а не бездумно индексировать всё подряд, понимая, для начала, что вообще из себя представляет индекс (физически) и чем нам "грозит" его построение.

Как легко и непринужденно мы вдруг перескочили на Postgres, ну да ладно. Т.е. сначала вы заявляли, что индексы в MySQL нельзя построить по JSON полям, потом оказывается вы имели ввиду по всем свойствам JSON объекта, окей, выкрутились.

Я их рассматриваю в разрере структуры хранения данных, и возможности альтернативы использованию Mongo (раз уж вы такой специалист, то может скажется в какой ситуации выгоднее будет монго чем mysql?).

Че-то странный вы персонаж, то значит спорите и доказываете, что можно создавать индексы для всех полей JSON объекта, а потом пишите что это на фиг не надо. Дак вы определитесь, надо или нет? Ведь если не надо, то какие претензии к MySQL? А если ответ "в каких то ситуациях нужно", дак в каких то ситуациях и нужно использовать не MySQL.

По этому, ещё разок: проиндексировать непосредственно JSON-столбец - нельзя, от слова совсем, т.е. никаким образом, ни таким как в MongoDB, ни таким как в PostgreSQL, ни каким-то ещё.

CREATE TABLE jemp (
	c JSON,
	g INT GENERATED ALWAYS AS (c->"$.id"),
	INDEX i (g)
);

То есть по вашему, люди используют MogoDB только по тому, что там были именно данные в формате JSON? "Нереляционные" (назовем их так) типы данных, например, XML появились в MySQL с версии 5.1, появились примерно в 2007г. XML принципиально хуже JSON'а?

Вы сейчас серьёзно? В MySQL, JSON-поля, это некоторый такой, костыль, который реально годиться для того, что бы хранить какую-то часть документа/записи/строки, которая имеет динамический формат (т.е. заранее неизвестные набор и/или схему данных). ...

А создание виртуального столбца на JSON столбец и создание соответствующего индекса, не является разве индексом по JSON столбцу? Забавно конечно.

Ну не совсем, если до этого приложение работало JSON данными "как есть" (либо с вьюхами, которые доставали поля из JSON средствами базы), то в коде приложения ничего не поменяется, т.к. "создаться" виртуальный столбец, который нигде никак не фигурирует, а индекс при этом будет работать).

В остальном, соглашусь что у каждой БД свое назначение, но хоронить MySQL из-за того, что есть Mongo, которая лучше в плане работы с не реляционными данными, и поднимать еще одну БД, чтобы хранить 3-5 сущностей, как то не огонь.

Так что, даже на текущий момент, Mysql JSON-костыль я считаю вполне рабочий инструмент для 40-60% ситуаций, когда нужна работа с неструктурированными данными.

Момент I:
1. Мы создаём столбец, с какими-то данными, JSON/XML/что-то-там-ещё (не важно), пусть он называется column1
2. Мы создаём второй столбец, который называется column2, вешаем на него индекс
3. Мы создаём триггер (и/или хранимую процедуру), вешаем его на "ON INSERT/UPDATE", по этому триггеру вставляем агрегированное значение в column2, например на основании некоторых данных из column1.
Вопрос - чем подобный механизм глобально отличается от процедуры "создание виртуального столбца"?

Не знаю, где именно вы имеете в виду "не фигурирует", у меня лично, этот столбец вполне себе фигурирует, точно так же как и любой другой столбец, в т.ч. в SELECT * FROM table1

И индексируется именно "этот" столбец, а не столбец с JSON-данными, на основании которого он [может быть] построен.

Более того, с учётом крайне интересной особенности MySQL, под названием "1 запрос = 1 индекс", то есть невозможности использовать более одного индекса в рамках одного запроса, подобная "индексация" JSON-столбцов выглядит крайне бесполезно, даже если бы MySQL умел их "нормально" индексировать.

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

SELECT * FROM features 
WHERE feature->"$.properties.STREET" = 'MARKET'

Насколько вижу я, как бы мы не "индексировали" этот столбец (JSON), при прямом обращении к этому столбцу (именно к JSON-столбцу), никакой индекс в выборке не участвует. Не зависимо от того, используем ли мы ту часть, данных на основе которой строится виртуальный столбец или нет.

CREATE TABLE features (
	id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
	feature JSON,
	feature_street VARCHAR(30) AS (JSON_UNQUOTE(feature->"$.properties.STREET")),
	INDEX (feature_street)
);

# при запросе к JSON столбцу, будет использоваться индекс по виртуальному полю
EXPLAIN SELECT * FROM features  WHERE feature->"$.properties.STREET" = 'MARKET'
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: features
   partitions: NULL
         type: ref
possible_keys: feature_street
          key: feature_street
      key_len: 33
          ref: const
         rows: 808
     filtered: 100.00
        Extra: NULL