Из JSON в реляционную базу данных
База данных может принять все вставки и всё равно выдать неверный бюджет закупок. Посмотрите, как неправильно размещённая цена портит каталог товаров и как Entity Enricher превращает проверенные решения об идентичности и связях в воспроизводимые таблицы и обновления.
Агент интерпретирует ваш JSON и пишет SQL. Supabase MCP выполняет этот SQL через apply_migration и execute_sql. Правила моделирования, идентичности и повторного импорта должны задавать ваш агент или приложение.
Вы проверяете переиспользуемую схему, включая ключи и связи — общие или принадлежащие родительской записи. Движок выводит таблицы, ограничения и структурные индексы, а затем передаёт последующие изменения данных через ту же модель. ИИ помогает предложить модель; правила применяет код.
Это сравнение описывает агента, который строит модель из JSON через Supabase MCP. Хорошо спроектированное приложение на Supabase тоже может реализовать эти механизмы защиты. Ошибочная модель ниже — иллюстрация риска моделирования, а не поведение Supabase по умолчанию и не измеренная частота сбоев.
Этот вымышленный каталог содержит два образца товаров. Поставщик SUP-7 продаёт лампу за 12 € и стол за 85 €. Поставщик общий; цена и срок поставки относятся к каждому предложению.
[
{
"sku": "LAMP-01",
"name": "Reading lamp",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 12,
"lead_time_days": 3
}
]
},
{
"sku": "DESK-02",
"name": "Writing desk",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 85,
"lead_time_days": 14
}
]
}
]В Entity Enricher это примеры схем, а не автоматический импорт данных. Проверьте сгенерированную схему, отметьте поставщика как общего, а предложения — как принадлежащие родительской сущности, затем опубликуйте и обогатите или добавьте соответствующие записи. Идентичность в этом примере обеспечивают стабильные SKU и идентификаторы поставщиков.
Пример ошибочного сопоставления
| Столбец и ключ | Тип SQL |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Столбец и ключ | Тип SQL |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Обновление SUP-7 предложением для стола перезаписывает цену и срок доставки лампы. Внешний ключ корректен. Данные — нет. Такая структура также ограничивает каждый товар одним поставщиком.
Entity Enricher с проверенной моделью
| Столбец и ключ | Тип SQL |
|---|---|
| skuPK | text |
| name | text |
| Столбец и ключ | Тип SQL |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Столбец и ключ | Тип SQL |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Одна строка поставщика используется повторно. У каждой пары «товар — поставщик» своя цена и свой срок поставки. Добавление предложения для стола не затрагивает предложение для лампы.
Имена таблиц и естественные ключи упрощены; метаданные синхронизации опущены. PK — первичный ключ, FK — внешний ключ. Два ключа предложения образуют один составной ключ. В этом примере предполагается одно актуальное предложение на пару; история цен, валюты или ценовые уровни по количеству требуют дополнительного моделирования.
Покупателю нужно 100 ламп. Переключайтесь между первым и вторым импортом, чтобы увидеть, что возвращает каждая модель.
Ошибочная модель: бюджет на 100 ламп
8 500 €
Завышено на 7 300 €. Ваш отчёт о маржинальности и прогноз закупок теперь используют цену стола.
Проверенная модель EE: бюджет на 100 ламп
1 200 €
Предложение для лампы остаётся 12 € со сроком поставки 3 дня. Предложение для стола — отдельная строка.
Иллюстративные расчёты на основе демонстрационных данных; без обращений к базе данных и без измеренных финансовых потерь.
При каждом импорте создаётся новый ID поставщика, и закупки распределяются по дублирующимся профилям. Итоги расходов и сравнение поставщиков становятся недостоверными.
Entity Enricher
Объявленные стабильные ключи позволяют повторяющимся сущностям сходиться. Необязательные семантические идентификаторы помогают, когда названия различаются, но такие совпадения всё же требуют проверки.
Ключ связующей таблицы, начинающийся с product_sku, не заменяет индекс, начинающийся с supplier_id. По мере роста каталога обратный поиск может стать затратным.
Entity Enricher
EE создаёт структурные индексы для своих связей, включая обратный поиск по связующим таблицам, и избегает избыточных индексов с тем же начальным префиксом. Остальные индексы настраивайте под ваши реальные запросы.
В вашем JSON появляется поле предложения, а в целевой таблице или SQL импорта — нет. Новые данные не загружаются или не доходят до отчётов, которым они нужны.
Entity Enricher
Опубликованная схема определяет и структуру таблиц, и проекцию данных. Перед публикацией просмотрите поддерживаемые миграции; неподдерживаемые преобразования блокируются.
После импорта обрывается соединение. Без правил повторного воспроизведения повторная попытка может создать дубликаты, а более старое обновление — заменить более свежее предложение.
Entity Enricher
EE обеспечивает упорядоченную доставку, upsert по идентичности и защиту по ревизиям. Клиент PostgreSQL применяет пакет в транзакции и подтверждает его после коммита.
Модель возвращает JSON, но в предложении нет обязательного ключа либо целевая база отклоняет запись. Одно лишь сообщение об успехе может скрывать отсутствующие товары и предложения.
Entity Enricher
Политики приёма могут отклонить сущность или пропустить неполные дочерние записи. EE сообщает о частичных результатах и отдельно отслеживает доставку в реплику, поэтому вы можете понять, что требует исправления.
Перезапись неизменившихся предложений нагружает базу данных, без необходимости обновляет индексы и добавляет шум в дальнейшую обработку изменений.
Entity Enricher
EE определяет неизменившееся состояние сущности и защищает строки от обновления неизменившимися значениями. Потребители могут отслеживать изменения, включая удаления, через поток дельт.
Перед публикацией проверьте идентичность, принадлежность и смысл каждого поля. EE делает эти решения исполняемыми, но не может доказать, что ваша бизнес-модель верна. Семантическое сопоставление может ошибаться, а производительность запросов по-прежнему зависит от нагрузки и размера базы данных.
Последнее обогащение заменяет текущее состояние: отсутствующие значения могут затереть прежние, а более короткий список принадлежащих предложений удаляет те, которые не указаны. При необходимости ведите историю отдельно. Частичные или отклонённые данные нужно исправить и отправить повторно; статус доставки не означает автоматического исправления.
Supabase MCP полезен, когда нужно, чтобы агент изучил базу данных и написал собственный SQL. EE полезен, когда один и тот же контракт данных должен постоянно давать согласованные реляционные обновления. Вы можете использовать Supabase PostgreSQL как получателя для клиента синхронизации EE — с учётом прав на подключение и доступ к базе данных. Политики доступа приложения вы настраиваете сами.
Проверено 10 сентября 2026 года. Supabase предоставляет миграции и Advisors, которые отмечают отсутствующие индексы; отличие EE — в генерации и применении правил на основе проверенной схемы обогащения.