YamlBox

Генераторы кода · 5 минута чтения

От JSON до SQL: от полезных данных к таблице, которую вы

Иногда самый быстрый путь от файла JSON к запросу SQL — это построить на его основе таблицу. Преобразование JSON в SQL создает схему и строки за один шаг, что идеально подходит для фиксации, временного анализа и заполнения локальной базы данных — при условии, что вы исключите ее из истории миграции.

Обновлено

Как типы сопоставляются с JSON на SQL

  • Строки → `TEXT` (`VARCHAR(n)`, если известен бюджет длины).
  • Целые числа → `INTEGER` / `BIGINT`, десятичные дроби → `NUMERIC`, а не с плавающей запятой, особенно для денег.
  • Логические значения → `BOOLEAN`.
  • Вложенные объекты и массивы → `JSONB` в PostgreSQL, `JSON` в MySQL 8 — или нормализуйте их в дочерние таблицы, когда данные останутся здесь.
  • Отсутствующие ключи → столбцы, допускающие значение NULL, никогда не используются по умолчанию, которые подделывают значение.

Сгенерированная таблица — отличная отправная точка и ужасная миграция. Напишите нужную схему, а затем используйте сгенерированный SQL в качестве ссылки для имен и типов столбцов.

Побег не является обязательным

Строки в JSON обычно содержат апострофы — `O’Brien`, `it's done` — и вставленные в SQL вручную, они досрочно завершают строку и нарушают оператор. Сгенерированные инструкции INSERT правильно удваивают каждую кавычку, и это самая полезная вещь, которую преобразование дает вам. Для массовых вставок оберните строки в один оператор, чтобы база данных могла выполнять пакетную запись вместо фиксации построчно.

Хорошее использование, плохое использование

Данные приспособлений для тестов, локальная рабочая копия экспорта API, заполнение демонстрационной среды и ответ на одноразовый вопрос в SQL — все это выигрывает от преобразования JSON в SQL. Управление производственной схемой не требует: миграция требует проверки, индексов, ограничений и пути отката. Создайте таблицу, а затем вручную напишите готовую миграцию.

Массивы и объекты: сгладить или сохранить?

Если массив представляет собой фиксированный список скаляров, дочерняя таблица с внешним ключом упрощает запросы. Если это действительно динамическая полезная нагрузка — тела веб-перехватчиков, сторонние метаданные — сохранение ее как `JSONB` и индексирование запрашиваемых путей является прагматичным выбором. Решите, как вы будете запрашивать его: все, что вы фильтруете или к чему присоединяетесь, принадлежит столбцу.

Запустите его в браузере

Экспорт базы данных и дампы API — это именно те полезные данные, которые не следует загружать в неизвестный сервис. Преобразование JSON в SQL здесь происходит полностью на странице, поэтому копируемый вами оператор создается на основе данных, которые никогда не покидали ваш компьютер, и инструмент по-прежнему работает в автономном режиме.

от JSON до SQL — часто задаваемые вопросы

Какой диалект SQL мне следует создать?

Нацельтесь на базу данных, с которой вы фактически будете ее запускать — PostgreSQL для `JSONB`, MySQL 8 для `JSON` и идентификаторов с обратными кавычками, SQLite для упрощенной локальной работы. Правила цитирования и имена типов в них различаются, поэтому регенерация для каждого диалекта важнее ручной адаптации.

Могу ли я вставить массивы JSON в один столбец SQL?

Да, в базах данных с типом столбца JSON: массив становится `JSONB` или `JSON`, и вы выполняете запрос к нему с помощью операторов пути. Если вам нужно объединить или агрегировать элементы, лучшей моделью будет дочерняя таблица.

Безопасно ли генерированное SQL при инъекции?

Сгенерированные инструкции можно запускать там, где вы захотите, а строковые значения экранируются как литералы. Они не заменяют параметризованные запросы в коде приложения — никогда не создавайте запросы путем объединения на сервере.

Инструменты, упомянутые в этом посте

Просмотрите полный список инструментов 19

Еще статьи для чтения

Все 19 публикации →