<?php
$pattern = preg_quote($searchText);
$pattern = "/^.*($pattern).*\$/im";
preg_replace($pattern, '<b style="color:red">$1</b>', $contents);Насколько вижу я, как бы мы не "индексировали" этот столбец (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Момент I:
1. Мы создаём столбец, с какими-то данными, JSON/XML/что-то-там-ещё (не важно), пусть он называется column1
2. Мы создаём второй столбец, который называется column2, вешаем на него индекс
3. Мы создаём триггер (и/или хранимую процедуру), вешаем его на "ON INSERT/UPDATE", по этому триггеру вставляем агрегированное значение в column2, например на основании некоторых данных из column1.
Вопрос - чем подобный механизм глобально отличается от процедуры "создание виртуального столбца"?
Не знаю, где именно вы имеете в виду "не фигурирует", у меня лично, этот столбец вполне себе фигурирует, точно так же как и любой другой столбец, в т.ч. в SELECT * FROM table1
И индексируется именно "этот" столбец, а не столбец с JSON-данными, на основании которого он [может быть] построен.
Более того, с учётом крайне интересной особенности MySQL, под названием "1 запрос = 1 индекс", то есть невозможности использовать более одного индекса в рамках одного запроса, подобная "индексация" JSON-столбцов выглядит крайне бесполезно, даже если бы 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-данных. 3 строчки про GIN. Что нам MySQL предоставляет в качестве альтернативы GIN-индексам... дайте подумать... примерно, ничего?
Прочитайте документацию по другим БД, и тогда вопрос "как можно индексировать JSON-поля?" отпадет сам собой.
Если немного подумать, то херь несёте именно Вы, достаточно взять одно только высказывание, про то, что "MongoDB можно заменить на MySQL без каких либо проблем". Вы берете во внимание исключительно какой-то удобный для подобного утверждения пример, забывая примерно обо всех индивидуальных особенностях этих двух БД. Таких как скорость обработки данных например, общую концепцию работы и так далее. Если бы базы так легко (как вы думаете) взаимозаменялись - достаточно было бы одной БД а MongoDB вероятнее всего, вообще не появилась и вряд ли бы она стала развиваться, а какие-то люди (исходя из вашей логики) - не понимающие прописной истины, которая заключается в том, что в MySQL тоже есть JSON (или возможность туда его добавить) - не стали бы вкладывать сотни тысяч $$$ в развитие MongoDB.
Это ещё один момент, который показывает крайне не высокий уровень вашей квалификации, который вы так усердно пытаетесь приписать мне. Конкретными - поля (ключи) становятся исключительно в момент запроса, а сама по себе структура - может многократно и динамически меняться в режиме "от случая к случаю". Есть миллион вариантов, при которых нам может понадобиться поиск по динамически выбранному набору полей, который при этом будет "всеми полями" для одного отдельно взятого документа. И индексацию в этом случае, можно проводить так же - динамически, главное делать это с головой, а не бездумно индексировать всё подряд, понимая, для начала, что вообще из себя представляет индекс (физически) и чем нам "грозит" его построение.
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)db.products.createIndex( { "category": 1 } );Мои работы до сих пор радуют некоторых крупных заказчиков, как местных так и иностранных (включая международные компании), некоторые из которых входят в ТОП Форбс'а. Некоторых других не менее радуют ряд специалистов, подготовленных лично мной, в т.ч. специалистов международного уровня.
Из MySQL неможно сделать MongoDB и вообще - конкретно это Ваше утверждение ничем не подкреплено. Только то, что и в MySQL и поддерживается одинаковый формат данных - не говорит о взаиомозаменяемости одной базы другой.
Какие? Ссылку на документацию по этому вопросу, пожалуйста.
Я то как раз недавно, в отличии от Вас видимо :))) Вы понимаете, чем отличается Maria от MySQL и тот момент, что Maria была реализована явно не с целью и желанием реализовать поддержку SQL-стандартов, которой нет в MySQL? И уж явно никоим дрыком на данный момент в MariaDB SQL-2016 не реализован.
Кто из нас не знает на самом деле - мы сейчас выясним...