Меня просто очень удивило, что сам вопрос структуры хранения данных уже внутри json столбца оказался с подвохом. Мы получаем ситуацию, когда ни один формат данных из двух приведённых выше не поддерживается всеми их (SQL) командами.
То, что поддерживается JSON_TABLE, не поддерживается, к примеру, JSON_SET, где нужен наоборот уникальный ключ, либо тогда уже указать позицию нужного объекта - всё это лишние действия и уже не так удобно, как предполагалось.
Роман, я изучил эту функцию (правда документация ссылается на её доступность только с MySQL 8.0.4 и поздних версий), и это пока видится очень даже удобным решением в некоторых сценариях.
Только вот я всё перерыл и нигде не нашёл, можно ли делать join разных таблиц, где одна из используемых в join-е как раз создаётся через json_table. В документации указано:
An inner join can be emulated by applying a suitable condition in the WHERE clause, as shown here
Вы не знаете, можно ли делать такие join-ы, то есть вместо "tbl_name" подставляя json_table функцию?
Евгений Самсонов, я сам по специальности не из IT, я владелец проекта, но вынужден в такое вникать, потому что жизнь показывает, что никому неинтересно, кроме меня, как сделать лучше. Сделают на подряде так, чтобы работало. Потом окажется, что могло в 20 раз быстрее работать.
Я стараюсь рассматривать все варианты, про это тоже уже читал. Пока я не очень понял, какие именно преимущества я получу от такой миграции. Я соотнёс преимущества NoSQL и не вижу, чтобы они были мне нужны именно в моей ситуации. У меня кроме описываемой таблицы ещё очень много таблиц, но те пока полностью укладываются в реляционную модель.
Пока что поиска по этим полям не планируется. Достаточно просто извлекать массив из нужной ячейки целиком.
Я думал над таким вариантом тоже. Всё отлично, но никак не придумаю, как лучше всего избегать скачков в весе строк. К примеру:
uid | json_array
1
2
3
4
5
6
...
26
Если создавать ячейку пустой при создании юзера, то позже, если юзер будет заполнять профиль содержательнее и его поле с массивом будет увеличиваться, это будет происходить уже в глубине таблицы. Значит, будут постоянные смещения индексов по страницам.
Есть вариант подсчитывать, сколько в среднем весит массив в таблице и набивать его изначально при создании юзера, к примеру ключами с кодами 999, за которыми будет стоять "Нет ответа". Но как-то это всё коряво и странно, должно быть что-то удобнее...
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Меня просто очень удивило, что сам вопрос структуры хранения данных уже внутри json столбца оказался с подвохом. Мы получаем ситуацию, когда ни один формат данных из двух приведённых выше не поддерживается всеми их (SQL) командами.
То, что поддерживается JSON_TABLE, не поддерживается, к примеру, JSON_SET, где нужен наоборот уникальный ключ, либо тогда уже указать позицию нужного объекта - всё это лишние действия и уже не так удобно, как предполагалось.