🗄️ SQL и базы данных · 20 вопросов · ~41 мин · ⏱ Таймер 41:00 · Сложный ·

JSON в реляционной базе

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 41 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Какие данные разумнее оставить обычными столбцами, а не переносить в attributes jsonb?

Редко используемый необязательный параметр, встречающийся у одной категории товаров Первичный идентификатор, цена и внешний ключ производителя Набор необязательных параметров импортированного товара Экспериментальная характеристика, состав которой меняется

Вопрос 2 из 20

Почему jsonb обычно удобнее json для фильтрации и индексирования в PostgreSQL?

CREATE TABLE products (attributes jsonb NOT NULL DEFAULT '{}'::jsonb);

jsonb хранит документ компактнее json независимо от размера и структуры jsonb проверяет ссылки между ключами документа и строками других таблиц jsonb удобен для структурных операторов и индексов jsonb сохраняет исходные пробелы и порядок ключей точнее

Вопрос 3 из 20

Что не так со схемой, где имя клиента, email, статус заказа и все позиции хранятся одним jsonb?

Такой документ нельзя получить одним SELECT без предварительного VIEW jsonb допускает только числа, boolean и вложенные объекты, но не строки Сложно обеспечить уникальность email, внешние ключи, типы и эффективные связи по основным сущностям Массив позиций разрешён в json, но не в jsonb PostgreSQL

Вопрос 4 из 20

Столбец data уже объявлен jsonb NOT NULL. Как гарантировать, что в документе есть строковый ключ currency?

CHECK (data ? 'currency' AND data->>'currency' <> '')CHECK (data ? 'currency') CHECK (data ? 'currency' AND jsonb_typeof(data->'currency') = 'string') CHECK ((data->>'currency') IS NOT NULL)UNIQUE ((data->>'currency')) CHECK (jsonb_typeof(data) = 'object' AND data ? 'currency')CHECK (jsonb_typeof(data->'currency') = 'string')

Вопрос 5 из 20

В документе tags — массив строк. Какой вариант сохраняет именно массив, а не строку с квадратными скобками?

'{"tags": "[sql,postgres]"}'::jsonb to_jsonb('sql,postgres'::text) jsonb_build_object('tags', 'sql,postgres') '{"tags": ["sql", "postgres"]}'::jsonb

Вопрос 6 из 20

Что вернёт оператор -> в этом запросе?

SELECT '{"city":"Moscow"}'::jsonb -> 'city';

Текст Moscow без кавычек Весь объект address JSON-строку "Moscow" NULL

Вопрос 7 из 20

Почему условие price = 100 не сработает после извлечения через ->>?

SELECT data->>'price' AS price_text FROM offers;

Структурное условие по JSON разрешено только через оператор @>, но не через извлечённое значение ->> удаляет ключ price ->> возвращает text, а не число Оператор ->> округляет числовые значения и возвращает уже готовое integer

Вопрос 8 из 20

Как извлечь вложенный postal_code сразу как text?

data @> '{"address":{"postal_code":true}}' data #> '{address,postal_code}' data -> 'address' -> 'postal_code' data #>> '{address,postal_code}'

Вопрос 9 из 20

Что делает оператор ? в выражении data ? 'discount'?

SELECT id FROM offers WHERE data ? 'discount';

Проверяет наличие ключа верхнего уровня discount Проверяет, равно ли значение ключа discount SQL-значению NULL Удаляет ключ discount из объекта и возвращает изменённый документ Извлекает значение discount и сразу приводит его к numeric

Вопрос 10 из 20

Ключ address уже существует и содержит JSON-объект. Как изменить только address.city, сохранив остальные ключи?

data || '{"city":"Таллин"}'::jsonb data->'address'->>'city' = 'Таллин' jsonb_set(data, '{address,city}', '"Таллин"'::jsonb, true) replace(data::text, 'city', 'Таллин')::jsonb

Вопрос 11 из 20

Как найти документы, содержащие пару status=paid?

data = 'paid'::jsonb data::text LIKE '%paid%' data @> '{"status":"paid"}'::jsonb data->'status' IS TRUE

Вопрос 12 из 20

Почему LIKE по data::text может дать ложное совпадение?

WHERE data::text LIKE '%paid%'

Фрагмент может находиться в другом ключе или тексте LIKE сравнивает только числа Приведение jsonb к text оставляет границы полей, поэтому LIKE сопоставляет только значение нужного ключа LIKE ищет только в значениях верхнего уровня и не затрагивает имена ключей

Вопрос 13 из 20

Как получить по одной строке на каждый элемент массива tags?

SELECT unnest(data) FROM articles SELECT jsonb_array_elements_text(data->'tags') FROM articles SELECT split_part(data::text, ',', 1) FROM articles SELECT data->>'tags' FROM articles GROUP BY tags

Вопрос 14 из 20

Что произойдёт, если напрямую привести data->>'age' к integer, а в одном документе лежит "не указано"?

SELECT (data->>'age')::integer FROM profiles;

Строка будет пропущена автоматически Неверное значение станет нулём Запрос завершится ошибкой приведения Получится JSON null

Вопрос 15 из 20

Как найти товары, у которых массив tags содержит строку sale?

attributes::text = 'sale' attributes ? '{tags,sale}' attributes @> '{"tags":["sale"]}'::jsonb attributes->>'tags' = 'sale'

Вопрос 16 из 20

Какой индекс чаще всего помогает условиям вида attributes @> ...?

CREATE INDEX ON products USING GIN (attributes); CREATE INDEX ON products USING HASH (attributes::text); CREATE INDEX ON products (length(attributes::text)); CREATE UNIQUE INDEX ON products (id, attributes);

Вопрос 17 из 20

Запрос всегда фильтрует по (attributes->>'sku') = $1. Что может быть точнее общего GIN?

CREATE INDEX ON products (attributes->'sku' = $1) CREATE INDEX ON products USING GIN ((attributes->>'sku')) CREATE INDEX ON products ((attributes->>'sku')) CREATE INDEX ON products (sku) WHERE attributes IS NULL

Вопрос 18 из 20

Почему индекс по всему jsonb может оказаться дорогим для часто меняющегося документа?

GIN-индекс не допускает UPDATE строк, пока индекс существует Полный GIN-индекс хранит только сериализованный текст документа, не отдельные ключи Каждое изменение документа требует обновить индексные записи для его содержимого После создания индекса значение jsonb становится неизменяемым

Вопрос 19 из 20

Почему индекс выражения должен повторять выражение запроса?

CREATE INDEX ix_email_ci ON users (lower(profile->>'email'));
SELECT * FROM users WHERE lower(profile->>'email') = lower($1);

PostgreSQL сравнивает только длину SQL-текста Индекс используется для совпадающего выражения Любое выражение использует любой индекс Индекс выражения работает только в SELECT *

Вопрос 20 из 20

Что следует сделать перед добавлением большого GIN-индекса?

Удалить ограничения таблицы, чтобы построение индекса не проверяло целостность Перенести в JSON все столбцы таблицы, чтобы один индекс обслуживал любые запросы Проверить частые запросы, объём, долю обновлений и план выполнения на реальных данных Создать GIN на каждом jsonb-столбце, не проверяя частоту записи и тип операторов

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу