Колонка JSON OR Традиционные столбцы

Question

Моя команда работает над модулем выставления счетов, где наши пользователи должны иметь возможность добавлять позиции в счет-фактуру и хранить эти позиции в нашей базе данных. Эти позиции можно редактировать после первоначального создания.

Позиция счета будет выглядеть примерно так.

LineItemName 
EnteredBy 
Quantity 
CostPerUnit 
Subtotal 

Один из членов нашей команды предполагают, что мы храним данные строки в столбец JSON, а не в нескольких столбцах SQL. Его аргумент заключается в том, что будет проще хранить все данные позиции в одном столбце JSON, а не писать код, чтобы определить, какие позиции могут быть удалены, обновлены, перенаправлены или иным образом обработаны из исходного состояния базы данных.

Я раньше не работал с колонками JSON, и из того, что я могу сказать, при использовании этих функций возникает ряд проблем с производительностью, а также некоторые дополнительные сложности при построении запросов от столбца данных JSON. Нам придется отчитываться об этих позициях, поэтому производительность, безусловно, вызывает беспокойство. Мы также запускаем SQL Server 2012, который, как я понимаю, не содержит встроенной поддержки столбцов JSON, если мы не обновляемся до SQL Server 2016. Боковое замечание, скорее всего, мы перейдем к MYSQL в течение следующих 2-3 лет.

Может ли кто-нибудь дать некоторые рекомендации относительно того, что здесь правильный звонок? Мой инстинкт заключается в том, что мы должны использовать существующие методы и написать дополнительный код для обнаружения изменений базы данных, чтобы избежать головной боли проблем с производительностью и сложности отчетности позже.

Answer 1

Короткий ответ: Не храните в JSON, используйте колонки, вот почему они есть.

Длинный ответ

Вы используете реляционную базу данных для хранения данных, использовать функции, что эти программные которые предоставляют для хранения и упорядочивания данных.

Как уже было указано в комментариях, сохранение значений в отдельных столбцах позволяет выполнять различные агрегации, фильтруя их по этим столбцам без накладных расходов на разбор нереплицированной структуры данных (скорее всего, используя сторонний плагин/CLR/функция/все).

Дополнительно Данные JSON не имеют фиксированной структуры. Вы не можете проверить согласованность данных, хранящихся в поле JSON, без разбора поля и написания пользовательских проверок.

Сохранение несколько данных в одном поле также означают, вы не можете (или не легко)

• используют ограничения на встроенном полом
• вы не можете обеспечить структуру, допустимые диапазоны, действительным значения для каждого из полей для встроенных полей
• определяют тип данных вложенных полей
• индексных данных (ни один не включать их)
• агрегатный/поиск в этих областях
шкала
• система
• запрос метаданных, список полей и т.д. для вложенные

Сервер базы данных не может

• Keep отслеживать статистику индекса для каждого поля
• оптимизировать запросы с использованием поля JSON (из-за строковых операций, необходимых для извлечения данных)
• не может сохранять данные для каждого поля оптимально.

Вышеуказанные вещи важны, но ни один из списков не является полным.

Что вы выиграете?

• Некоторые названия полей.
• Некоторая гибкость в базе данных, но гораздо более сложные функции в приложении, поскольку все проверки должны выполняться в приложении дважды - когда вы хотите писать и когда вы читаете данные.
• Огромная головная боль, когда вам нужно что-то исправить в поле JSON.

В качестве альтернативы вы можете использовать столбцы XML, они поддерживаются SQL Server, и некоторые из перечисленных выше проблем не являются проблемой, НО: у нее по-прежнему нет фиксированной структуры. (если он есть, вы можете хранить данные в традиционных столбцах. В обоих случаях вам нужно указать структуру вручную).

В качестве примечания: формат, который вы выбираете для хранения данных, конечно, основан на мнениях, но, как правило, используйте традиционные столбцы, когда они могут удовлетворить ваши потребности, и избегать использования сериализованных данных. Особенно, если вы хотите использовать только некоторые его части для любого расчета.

Когда вы можете хранить сериализованную данные: Когда это не важно для обеспечения согласованности, и вы никогда не будете использовать его для статистических запросов или для фильтрации. (Тем не менее, в большинстве случаев, не расстается это не так :))

Answer 2

Я постараюсь дать несколько иной ответ :)

Используйте реляционные столбцы, если вы ожидаете много обновлений и расчетов. Лучше всего использовать ссылки и обновлять столбцы, обновляя и ссылаясь на поля JSON. В этом случае вы оптимизируете производительность DML и, вероятно, некоторые аналитические.

Используйте JSON/XML, если у вас есть информация, которая редко изменяется, и если вы хотите избежать слишком большого количества JOIN, или если приложение ожидает JSON. В этом случае вы будете оптимизировать производительность чтения и загрузки.

В предыдущем ответе вы можете увидеть много преимуществ схемы отношений, и я не могу утверждать, что это неправильно. Однако я бы упомянул несколько случаев, когда JSON может помочь:

1. Представьте, что у вас есть большие столы, где вам нужно присоединиться к счетам 100K с 1M счетами-фактурами. В реляционной модели у вас будет два сканирования таблицы и JOIN, тогда как с JSON/XML у вас будет односкатное сканирование. Если ваше приложение ожидает отклика, отформатированного как JSON (например, вы отправляете позиции как JSON в угловой, нокаут или другой шаблон JavaScript через вызов Ajax), JSON будет идеальным выбором. Представьте, как будет выглядеть запрос на более сложную структуру по сравнению с однострочным сканированием таблицы с помощью JSON. De-normalization - один из самых старых трюков, которые улучшают производительность запросов, а JSON - это лишь один из методов де-нормализации, таких как материализованные представления, агрегации в кубах OLAP и т. Д. Это не решение всех ваших проблем, но оно помогает в некоторых сценариях.
2. Представьте, что вам нужно импортировать родительские/дочерние таблицы. Вам нужно импортировать одну строку счета, взять идентификатор @@, использовать эту личность, чтобы вставить связанные позиции, и повторить это для каждого импортированного счета. Альтернативой будет принудительный идентификатор, установив IDENTITY INSERT ON. С JSON/XML, если у вас есть элементы, отформатированные как JSON как часть каждого счета, вы можете использовать простой массовый импорт, который является самым быстрым способом загрузки данных.

Это некоторые причины, по которым люди переключаются на NoSQL (например, MongoDB или Azure DocumentDB). В SQL 2016 будет поддерживаться JSON, а в предыдущих версиях вам нужно будет использовать XML, но принципы одинаковы.

В вашем случае кажется, что вы будете часто обновлять позиции и вам не нужен быстрый сценарий чтения/загрузки, поэтому я бы предложил схему отношений.